Success-Plan Services
Jason Upchurch
**Please note that with the April 2024 release of Connext Professional 7.3 LTS, the functionalities formerly comprising Connext Secure are now available as an optional component to Connext Professional, named Security Extensions.
Part 1 of a Multi-Part Series
Protecting mission-critical industrial IoT environments requires security that scales from edge to cloud, across systems and suppliers. As a lead author of the OMG DDS Security standard, RTI has played a leading role in defining the requirements - and environments - that are necessary to secure distributed environments. DDS Security plugins provide robust, data-centric security mechanisms for data on the wire. RTI Connext DDS Secure is the proven, trusted connectivity framework that protects systems through flexible, fine-grained security for optimal performance and efficiency, from device to cloud.
We recognize, however, that security is a complex issue. While RTI has created high-grade security in the Connext DDS software framework, our research team is looking at other areas to drive more robust security into IIoT. With this in mind, we are happy to share with you some of the work from RTI Research, as they explore new and innovative approaches to security.
In this blog series, our security expert Jason Upchurch looks beyond the software to hardware mechanisms which provide security on an untrustworthy system where a critical application processes its data. In the spirit of pushing the security envelope, he explores Intel SGX® within the context of RTI Connext® DDS Micro and Security Plugins.
So let's get started.
What is SGX and Why Does it Matter?
SGX, or Software Guard Extensions, is an extension to the Intel ISA (Instruction Set Architecture) that provides a TEE (Trusted Execution Environment) to run applications that contain sensitive data. While it is true that Intel ISA does not dominate the Industrial IoT (IIoT), it does have market share in the server room, and the server room is often incorporated into various IIoT architectures. More to the point, these server room data processing applications are more likely to be high-value targets of malicious users, as they may have more access to protected data than traditional IIoT endpoints. Thus, SGX could very well help secure the IIoT, or at least a part of it. Let’s explore why SGX matters to DDS users and other application developers that require high-security environments.
Figure 1: Connext DDS Secure Inside SGX Space
Over-the-Wire Security May Not be Enough
To start, let’s look at the classic Alice and Bob academic example of sharing a secret. The story begins with Alice and Bob meeting in person, progresses with a devious Eve intercepting messages on the wire, and ends with a proven method to share secrets. This is the basis for secure communication, even if Eve intercepts all messages. Having run several of the world’s largest intrusions investigations, I can safely say that I have never seen “Eve” intercept encrypted messages on the wire and gather secrets. I can also say with certainty that “Eve” almost always gets the secrets she is after. These seemingly contradictory statements can both be true because network encryption is robust and, therefore, rarely the target of attack.
To examine the issue, let us look at the scenario, where Eve sits between Alice and Bob and can hear and even manipulate messages at will. The scenario makes the assumption that Alice and Bob trust each other with the secrets they are sharing; however, this assumption proves to be badly flawed in practice. The textbook diagram in Figure 2 actually illustrates the issue as Alice seemingly communicates with Bob at a distance without any technology.
Figure 2: Textbook Alice and Bob communication
The reality of the situation is that some form of device is used to enable Alice and Bob to communicate, and this is where our assumption gets the better of us. In computer security, there is a concept known as the Trusted Computing Base (TCB). In its simplest terms, TCB is all of the components (both individually and as a system), including software, that you must trust to secure some sort of processing. In our classic Alice and Bob scenario, we are attempting to secure the sharing of secrets at a distance. It is true that Alice makes the assumption of trust in Bob to share secrets with him, but she is also trusting his computing environment (and hers). In a real-world scenario, this is an ensemble of hundreds of components from various manufacturers that is (a) likely running an operating system with millions of lines of code; (b) is full of applications coded by people you don’t know; and (c) likely connected to a publicly-facing network that allows attackers and auto propagating malware free access to attack the system at will. These systems are far from trustworthy, to say the least.
...the situation is analogous to building a steel door with elaborate locks on a house with paper walls.
It is the source of cynical humor for many in the computer security community when some new and better encryption scheme is recommended to encrypt communication over the wire. After all, secrets can be just plucked with little effort from the source or destination, fully in the clear, without worrying about encryption at all. I have always thought that the situation is analogous to building a steel door with elaborate locks on a house with paper walls.
So what is to be done? The current approach in industry is largely centered on finding the minimum viable components (hardware and software) necessary to achieve a critical task, certify and/or measure each component, and isolate them from other components in the system. At a very basic level, this approach shrinks the TCB and verifies that no component inside of the TCB has been added or modified.
Security at the Endpoint (and Every Point in Between)
It is useful to note that, while not trivial, we have reached the point in computing that it is possible to build a secure computing environment. The issue is that current market demand is for a rich computing environment, which is at odds with a secure one. Even in IIoT, the demand for rich computing environments is not always for the vast functionality they offer, but because they are popular and well supported, thus much cheaper to develop upon and maintain. So the large TCB problem finds its way into devices that could be secured with another approach. In answer to the issue, industry has taken to architecting systems that provide both a rich operating system and a (somehow) separated Trusted Execution Environment (TEE) in a single device.
Most TEE designs essentially have two operating systems running in parallel on a single device. The rich operating system handles common tasks, and the secure operating system handles sensitive tasks. The TEE design allows for switching between the two. The switch is often hardware supported and enforced. Common trust mechanisms – such as root of trust chain loading – are used on the secure side to ensure no unauthorized code has been introduced.
SGX is quite different. Even a secure side TCB can be quite large. The root of trust only ensures that a program is unaltered upon loading. As such, its security depends on software validation techniques for every loaded program (including the minimal OS) as much as its trusted booting process. Intel set out to radically minimize the TCB. The attack surface in an SGX-enabled processor is the CPU and the application. There is no OS, firmware, hypervisor, other hardware or BIOS that needs to be trusted in a SGX environment. The only software that must be trusted is the application itself. SGX provides a method to ensure trusted loading of that application in much the same way as a normal trusted boot, except that the trust chain is only 3 links long (Root Attestation, CPU, Application) instead of the rather long chains in a traditional secure boot system.
Figure 3: Attack Surface in a SGX Environment
I have been experimenting with Intel SGX and DDS+Security. My objective is to run a DDS application in a protected area of a vanilla Ubuntu 16.04 with SGX enabled. The idea is that DDS protected-wire communication would arrive at the Ubuntu OS, then be passed into SGX-protected space. The DDS protection would be removed inside of the protected space. Then the data could be operated on by the application inside that protected area, which is opaque to the OS and to any malicious users/software present on the system. As this operation would be opaque to the OS (a combination of CPU protections/encryption), the results could be protected with Connext DDS Secure inside the SGX space and passed out the wire. Thus, there is no data exposure to the OS or to any part of the system besides the CPU and the application. A system admin or attacker with root (or root+) access to the system has no access to application data as lateral, and privileged attacks cannot gain access to SGX space.
This is Part 1 of a multi-part series that goes into depth on this topic. For more information on this topic, please contact me directly.
About the author
Jason Upchurch is a Cyber Security Research Scientist at RTI. Dr. Upchurch came to RTI from Intel Corporation where he was a Platform Security Architect and the Principal Investigator for a joint security laboratory with the US Department of Homeland Security, the United States Air Force Academy, and Intel. In addition to his work at RTI and Intel, Jason's security background includes serving as the most senior technical representative of the Cyber Protection and Digital Forensics Group at General Dynamics AIS and the Chief/General Manager of the Intrusions Group at the Defense Cyber Crime Center (DC3). Jason's operational service highlights include leading the forensic efforts in the early advanced persistent threat (APT) intrusions as well as several multi-million dollar financial intrusion investigations. Jason's research projects have included software similarity, compiled code reuse detection, hardware root of trust security, and hardware assisted attack detection. He received his Ph.D. in Engineering - Security at the University of Colorado, Colorado Springs.