Trusted computing for national defense

NASHUA, N.H. - We live in an era where the front lines of national defense extend far beyond geographical borders. A technological battleground exists in the invisible realms of cyberspace. Perhaps nothing -- save our warfighters -- is more vital to military success than keeping classified information out of rivals' hands. 

This information can be as varied as actionable intelligence like military movements, or it could be the secrets of game-changing technology that adversaries hope to reverse engineer. 

In a world where data is the lifeblood of national security, the integrity of every bit and byte is a matter of utmost importance. To ensure such sensitive information does not fall into the hands of any nefarious actors, the U.S. Department of Defense (DOD) insists on a trusted computing approach where systems are built on a foundation made with certainty in the supply chain, the hardware, the manufacturer, the software, the storage, and the end user. 

After all, there are myriad ways nefarious actors can attempt to get into a system -- from social engineering passwords or phishing attacks all the way to manufacturing counterfeit hardware or components to compromise a network or device. 

"Attacks are more sophisticated," says Dominic Perez, chief technology officer for the Curtiss-Wright Corp. Defense Solutions division in Ashburn, Va. "[Adversaries] are collecting data from multiple resources to try and exploit that human element in terms of cyber security and I don't know that for practical purposes that we can design that out. There's probably always going to be someone with a key or a password or a multifactor authentication that can get someone into a system. And people generally are trying to be helpful and they think they're doing the right thing, but if they don't have all the knowledge in the context that is required to operate in today's environment, then the mistakes are going to be made."

Zero trust 

Security can be made even more difficult when the DOD is pushing for a commercial off-the-shelf approach for embedded computing solutions. 

One way to make commercial IT components and systems secure from state actors who can buy them off the shelf and probe for vulnerabilities is to embrace a "zero trust" strategy. Zero trust architecture (ZTA) removes the implicit trust that a user should get access to the system solely because they, for example, know the correct passcode. 

Richard Jaenicke, marketing manager of Green Hills Software in Santa Barbara, Calif., says the DOD is progressing towards zero-trust implementation. 

"In January 2022, the DOD established the Zero Trust Portfolio Management Office (ZT PfMO) within the DOD chief information office (CIO)," Jaenicke says. "Then, in November 2022, that office published the DOD Zero Trust Strategy. The four strategic goals outlined in that strategy are: 1) Zero trust culture adoption, 2) DOD Information Systems Secured and Defended, 3) Technology Acceleration, and 4) Zero Trust Enablement. David McKeown, the DOD’s deputy CIO, said in May 2023 that his office has been partnering very heavily with commercial cloud providers and that the Defense Department is on track to implement its Zero Trust cyber security framework by fiscal year 2027 as planned.

He continues, "But zero trust isn’t just for cloud providers -- it can also apply to embedded systems. Most deployed embedded systems implement perimeter-based security at the edge of the embedded system. That can be as simple as a user ID/password combination granting broad admin-level privileges or something slightly more sophisticated like a firewall. Implementing zero trust starts with assuming that those perimeter defenses can be breached and not implicitly trusting any application already inside the perimeter."

The most secure embedded systems use a separation kernel to isolate applications, providing a base for zero trust. A separation kernel limits access to the least privilege necessary to get the job done. It also follows a policy of 'deny by default,' allowing only pre-approved information flow as defined in a static configuration file. Separation kernels have a very small attack surface and can be small enough to enable security evaluation of each line of code."

Curtiss-Wright's Perez explains that zero trust concepts "can really be applied up and down the stack all the way down to the hardware ... Don't just trust a user and their passwords, you need to understand the context. If Bob or Alice, have credentials to a system, but they don't generally go in and download a whole bunch of data from a system -- that is something that a good zero-trust architecture can be built to at least alert, if not automatically protect against.

"What we're doing when we're talking about trusted computing is that we're establishing that kind of base level of trust that we're building all of the systems on top of," Perez continues. "So, if I can't trust the operator, which we can address through user education, I can't trust the platform. If I can't trust the platform, if I don't know where it came from, I don't know who wrote the code that is operating the platform and I don't know its provenance and where it's been, did it get shipped through certain channels where it could have been tampered with. That is part of understanding your trust environment and your zero-trust environment, and there's bleed in there with supply chain and software supply chain management. So those are all very active topics of consideration."

Firming up

The foundations on which the zero-trust approach is built are assisted by firmware that enables systems to be booted and for constituent parts to communicate. 

Ben Warner, director of applications engineering for CRU Data Security Group (CDSG) in Vancouver, Wash., explains that his company, which specializes in removable storage solutions, flashes the stock firmware even when hardware comes from a trusted partner. 

"It's one thing to have the certification, but it's another thing to have a trusted supply chain and something that's actually vetted properly and ready to be used on a classified system," Warner says. "So some things that we do is we flash firmware, we don't use stock firmware that's been flashed out of the factory, even if it is a trusted source, and just additional precautions to make sure that everything coming out of our doors is not going to infect your system."

Another trend in the trusted computing for military applications noticed by Green Hills’ Jaenicke is banning container runtimes and orchestration engines. Container runtimes are an interface between the containerized application and the host operating system, which handles tasks like container creation, execution, and resource isolation. Orchestration engines are tools that automate the deployment, scaling, and management of containerized applications in a distributed environment. They ensure containers run reliably, efficiently, and at scale.

“Although the use of Linux containers has made some inroads into military and aerospace applications, there is a growing realization that containers lack the base-level security needed for national security systems,” Jaenicke says. “Containers and container orchestration systems bring the promise faster updates, but containers have long been known only to provide partial containment."

One example has the underlying mechanism for Linux containers called 'namespaces, yet "not all parts of the operating system kernel are namespaced," Jaenicke says. "The parts that are not namespaced can allow information leakage among containers and possibly allow containers to attack each other or the host."

Some container runtimes can allow information to leak backward through what was supposed to be a one-way communication channel. "Docker, as well as container orchestration engines, including Kubernetes, have been banned by the U.S. National Security Agency (NSA) from use in cross-domain systems (CDS), which connect networks of different classification levels. "The biggest advantage of containers is the ability to package the dynamic link libraries (DLLs) and other dependencies, but security is much higher with statically linked libraries and many embedded systems are built statically anyway," Jaenicke says.

The “holy grail” for secure and trusted systems is to be non-bypassable, evaluatable, always invoked, and tamperproof (NEAT). “When the security monitor is NEAT, all applications are guaranteed to be isolated from each other with no unauthorized information flow, Jaenicke says. “With enough effort, that is very achievable for software, as exemplified by [Green Hills Software’s] INTEGRITY-178 real-time operating system (RTOS) through its ability to meet Common Criteria EAL 6+ with high robustness. However, achieving NEAT for hardware is almost impossible because modern CPUs are too complex to be fully evaluatable or completely tamperproof. To make up for that, security systems can use redundant hardware solutions of independent design to provide defense in depth that prevents compromise from a single point of failure. The resulting hardware solution is Redundant, Always-invoked, Independent, and non-bypassable (RAIN). RAIN adds a great deal of complexity and cost but is very achievable."

Sensor safety

Today's military land, air, and maritime vehicles are filled with sensors generating an incredible amount of data. That data is a gold mine for bad actors, says Steve Petric, senior product manager for Data Solutions at Curtiss-Wright. "Everything is collecting data for post-analysis. The need for greater storage, expanding storage, and faster-performing storage, as well as secure storage plays into that. Artificial intelligence is an aspect of it. [Command] wants data so they can run their models...And the threats are not slowing down, right?” 

As an example, Petric describes sensor data from a captured military vehicle being of incredible use for an adversary, even if it's not going to be usable in the foreseeable future. 

"The harvest now, decrypt later," Petric says about the approach. "People are always trying to collect data. And what we're doing as a government, all the other adversaries are doing the same thing. They see all their vehicles as a way to collect sensor data and then the bad actors and internal threats -- that's always present. So, for us, it's never-ending for our customers. And unmanned vehicles, are you pushing that in places that maybe a human they would never push, right? So these are going into the most sensitive places. So, the need for rugged, secure, and now more so NSA-approved encryption is needed." 

While robust encryption is keeping sensitive data under wraps even if the vehicle were to fall into an adversary’s hands, that encryption might not always be enough thanks to potential breakthroughs made possible by quantum computing, which can leverage the principles of quantum mechanics to perform complex calculations at speeds unattainable by classical computers.

Unlike classical bits, which can be either 0 or 1, quantum bits or qubits can exist in multiple states simultaneously, known as superposition. This enables quantum computers to handle vast amounts of data in parallel and solve difficult, previously near-impossible problems, like cracking encryption. Thankfully, Curtiss-Wright’s Perez says that there’s likely to be time before quantum cracking is a major concern, though, given the nature of spycraft, we cannot be sure. 

“I don't believe there will be what we in industry call a ‘cryptographically relevant quantum computer’ for quite some time,” Perez says. “But along with that, I can tell you that our near peers are also working on those and they will not be issuing press releases when they achieve cryptographic relevance. There is on all sides a great deal of effort being put into harvesting data that's encrypted through conventional means for the day that it can be decrypted later. And the idea is that once we have that cryptographically relevant computer, this legacy encryption becomes almost trivial to break. And a lot of information that we protect with encryption is stuff that we need to keep protected for long periods of time, decades or more.”