Trusted Computing Hardware Features for Maintaining Cyber Security During Operation
April 25, 2018 | BY: David Sheets
Published in Military & Aerospace
It's important to understand hardware features that are built-in to the most popular defense and aerospace processor architectures to ensure the continued cyber security of a trusted computing system during operation.
Understanding these features - what they protect against, and how to use them effectively - will enable embedded computing systems to operate securely even in the face of cyber-attacks. Sometimes some software must be modified, as well, to take advantage of these hardware features.
First, it’s important to review one's own platform architecture to determine which features are available and relevant to the system’s requirements. Generally, the system integrator should use all security features that are available. Variables, such as cost, complexity, security requirements, and threat assessment, can influence the features that the designer will implement.
Each program should review requirements and make tradeoff decisions on security, cost, schedule, and complexity. Discussions with suppliers of commercial off-the-shelf (COTS) embedded computing components and subsystems at the earliest stages of system development can be of great help in making the right choices.
The QorIQ Trust Architecture from NXP Semiconductors, which is part of the Power Architecture and Arm-based devices, provides many hardware security features for secure processing during runtime. Because features of the Trust Architecture vary depending on the processor, it’s important to look at the platform to determine which features are available.
To protect sensitive memory from malicious data reading or writing, the QorIQ Trust Architecture implements I/O memory management units (MMUs) to prevent memory access without permission. These I/O MMUs prevent I/O devices from accessing protected memory regions my making sure that input cannot overwrite restricted memory regions. It also helps ensure the integrity of applications and data by protecting against unauthorized modification.
The QorIQ Trust Architecture provides a security monitor (SM) to sense and control the security state of the QorIQ. The SM monitors and responds to potential physical changes to the underlying security features in the hardware. After the QorIQ passes secure boot, SM enters a trusted/secure state, where the SM monitors the QorIQ’s security.
If it detects a security violation, the SM can respond with actions ranging from master key lock-out to full system-on-chip (SoC) reset. Monitoring includes checking hardware fuses to verify that error correction is still in line, and that no bits have flipped unexpectedly. Hardware self-checks can detect failures.
The QorIQ Trust Architecture Run Time Integrity Checker (RTIC) can monitor for unexpected changes in system memory by periodically verifying that contents have not changed from what is expected. This sort of protection ensures that even if a cyber-attack modifies application contents, the system can respond to the attack. RTIC security is one example of a layered approach to system security, because it provides a second layer of defense able to notice and respond to attacks.
System development always involves a tension between securing the system and opening it up for debugging. Secure debug enables the hardware to manage the ability to debug by progressively shutting down the ability to debug through the system development cycle. Using QorIQ’s secure debug controller enables a range of accessibility, from a completely open system, to a system that requires authentication to debug, to a system that completely disables the ability to debug. This hardware capability ensures that system security can respond to the changing requirements during system development life cycle.
The secure debug controller in the QorIQ architecture controls fuse settings, which helps systems designers control the level of access available to external debuggers. Secure debug supports four levels of access: open, conditionally closed without notification, conditionally closed with notification, and closed.
When set up, the system is completely open, yet the user can restrict access by burning fuses via software instructions. Then the debug feature is available only after authentication. To lock down access to the debug feature completely requires the burning of additional fuses.
Intel security features
Intel builds security technology into their products, including their embedded IoT lines, with capabilities to ensure secure operation. Available for Skylake and newer processors, Intel’s Software Guard Extensions (SGX) act as a firewall to protect portions of memory from unauthorized access by using a security fence. This fence allows software code to interact -- but only via defined instruction sets that the processor provides.
The SGX instructions help systems designers define protected memory regions via software. Hardware enforces access to software-defined regions to provide an additional layer of defense. If an attacker injects code to gain unauthorized access, SGX blocks this malicious code from accessing another enclave’s data and instructions. SGX requires more than just modifications to the OS; it also requires modifications to application code.
A system typically runs either in supervisor mode or application code. When the OS finished its kernel operations and is ready to switch to running the application code again, it needs to un-set a bit in a jump register that enables it to move from privileged mode to un-privileged mode. Intel’s OS Guard provides a hardware mechanism that prevents a user from executing non-privileged application code when the system is executing in privileged mode. This helps the hardware protect a secure system from attacks that try to escalate privilege.
Arm and TrustZone
Arm IP-based processors not only support the secure operation hardware features of the NXP QorIQ Trust Architecture, but also support TrustZone to add another layer of defense on top of user mode and privilege mode. TrustZone helps designers set a bit to place user or privilege modes into trusted mode. This limits access for such operations as accessing memory regions, or to preventing code from being modified. TrustZone positions security at the heart of the hardware and enables fine-grain management of partitioning hardware resources. It also ensures that non-trusted code cannot gain unauthorized access to resources used for trusted operations.
Power Architecture, Arm, and Intel processors also support virtualization, which enables several different operating systems to run together on one piece of hardware. Virtualization enforces security at a level above the OS, and prevents unauthorized access from leaking to other operating systems. However, this level of security can introduce a performance penalty because of the overhead of virtualizing system resources.
Virtualization happens in two ways. First Type-1 hypervisors operate directly on the hardware. Type-2 hypervisors, on the other hand, operate on top of an OS. Type-2 hypervisors virtualize the host OS’s resources so several guest operating systems can use them. Virtualization works similarly to TrustZone in that it provides an additional level of execution privilege distinct from supervisor mode. This enables the hypervisor to manage resource requests from several guest operating systems.
Many military and aerospace systems, however, need even more security. This is where a COTS vendor with security experience can come in. A COTS vendor can design-in and optimize security at the component and module level.
It’s important to think of system security as more than just a collection of hardware features. Security results from understanding the system’s fundamental building blocks, how the system operates, and the potential attack vectors.
More information on Curtiss-Wright’s Trusted COTS (TCOTS) Program for protecting critical technologies and data in deployed embedded computing systems is online at www.curtisswrightds.com/technologies/trusted-computing.
Read the full article here