Paper Discussion 8b: Securing Real-Time Internet-of-Things

[chandaweia]

Please add your feedback and reviews below.

[mjhegarty]

Reviewer Michael Hegarty Type Comprehensive

Problem being solved

A new type of system is becoming more popular in various industries where real time embedded devices are connected to the internet(RT-IoT). These systems unlike standard IoT systems have safety and timing requirements that need to be meet due to the potential critical of their use and could have human safety risks and other physical consequences if they are not met. Due to these requirements and consequences cyber attacks to these systems could cause irreversible damages and should not be taken lightly. Code injections can occur where the malicious code still meets timing requirements hiding its true nature. Side channel attacks are particularly dangerous due to the deterministic nature of RT-IOT devices. Systems need to leverage between network security and network performance to that it can stay secure while also meeting timing requirements.

Contributions

The paper sums up various threats to these RT-IoT devices(some of which I mentioned above) and summarizes 6 different solutions for IoT security, some in software and some in hardware. Simplex is an architecture that features a secondary secure controller that can keep the system from having real world consequences even if the primary controller is under attack. They propose maintaining system security via periodic resets so that no new code can be added to the machine and it can fix itself if failures occur. They propose a cache flushing system where caches can be flushed when going from a higher security level process to a lower one. They propose different random scheduling models to help combat the predictability of the RT-IoT system being exploited. Lastly they talked about different models of where to integrate security into already existing task scheduling systems.

Questions

1. For Resecure, is resetting the system something that can be done frequently enough to save a UAV from being sent straight into the ground without extracting large overheads from reading the entire system from memory?
2. The idea that they brought up of randomly switching between processes every tick seems very unfeasible to me. It seems like you would need a very long tick interrupt frequency to not be wasting all of your time context switching which would limit the speed at which your system could do things.What are some use cases for this where the most important part of the system is making sure it is not behaving in a deterministic way?
3. For Simplex, why not take it a step further and have every sensor and actuator have a safety controller attached to it that prevents uncharacteristic behavior?

[gkahl]

Reviewer: Greg Kahl

Review Type: Comprehensive

Problem

As the internet of things is growing, even more devices are being connected to the internet. Specifically, there has been a large increase in not only IoT devices, but IoT devices with a real time component in them. These take input from the physical world and the cyber system responds to the inputs it senses. A lot of the real time systems are used in unmanned surveillance and vehicles (such as drones and self driving cars). These real time systems become harder to secure because of the added difficulty of the low response time needed for many of these real time systems, especially when the consequences of these systems can be severe (harm or even death to humans).

Contributions

This paper explores the security threats specific to these real time systems. After looking at what these threats are, they then go through multiple possible solutions for these types of threats. The threats they explored included were code injection attacks, Denial of Service attacks, side channel attacks, and attacks via communication. Two of the solutions proposed were for code injection and denial of service attacks. The first, simplex, used a trusted piece of hardware separate from the system to monitor the control flow to ensure it hadn't been compromised. The second was a method to design systems which would reset when compromised in order to eliminate the threat. In regards to side channel attacks, one proposed solution was to flush the caches between execution of processes which need to avoid leakage of information. The next was to implement a randomized scheduler to prevent analysis of the order tasks are scheduled to gain information from the system. Finally, they discussed ways to set the priority of security tasks. Because these systems are real time, having high priority security tasks will slow down the system considerably. The first approach was to have the security tasks at the lowest priority, but they also proposed a dynamic security priority that lowers when the system is deemed safe, and raises if an anomaly appears.

Questions

1 - Is the idea of resetting a system frequently feasible? Especially with these real time systems that need low latency when controlling something like an airplane or a car. It seems like it could be dangerous if an immediate response is needed while the device is rebooting. 2 - The idea of randomizing the scheduler seems like a reasonable way to hide the patterns of the scheduler, but aren't those patterns there for a reason? It seems like by doing this you remove the priority aspect that lets these real time systems have high priority tasks for critical outputs. 3 - In SecureCore, is it unsafe to have the normal memory usage patterns recorded on the system? That is what the attacker would be after anyway and now its consolidated in one place

[searri]

Reviewer: Rick Sear Review Type: Critical

Problem being solved

Real-time systems have a serious downfall: their higher Internet-connectedness means they are a big target for cyber attack. Additionally, real-time systems tend to interact with the world a lot, so when they are hacked, serious problems can occur.

Important areas

This survey defines a subset of IoT: Real-Time Internet-of-Things. RTIoT is more vulnerable to attack than IoT because the real-time capability necessitates a better quality of network connection, and also because of the mixed priority levels which can be exploited to learn confidential information about the system. They propose some solutions, implemented in both hardware and software.

Questions about the survey

• ScheduLeak (Section 3.2.1) sounds interesting! I would like to learn more about it. How does it work? I don't fully understand it after reading this section.
• Table 2 lists schedule randomization as a way to prevent side-channel attacks, and 4.2.2 talks more about this. How much does this affect the functionality of the system? I ask because surely there's some effect if high priority tasks aren't actually treated as high priority. They say it's still subject to deadlines, but doesn't that make it still very predictable? I don't quite fully understand the TaskShuffler solution.
• Section 5.3 talks about using Software Defined Networking as a way to secure time-sensitive communications. What exactly is SDN, and what kind of capabilities does it need to be "retrofitted" with to be useful for RTIoT?

Critiques about the survey

• SecureCore doesn't seem feasible to me for a limited-resource setting. They propose a memory-virtualized (expensive) security monitor which uses clustering algorithms (also expensive) to learn legitimate software using system call frequency. Has this been tested somewhere? What kind of overhead is there?
• ReSecure: have you tried turning it off and on again? This idea seems comical but also potentially effective. I'm wondering, however, if this introduces a new security risk: what if an attacker gains access to the restart procedure and causes the system to restart too often or at inopportune times? If this is all they have to target, the "it will take longer for an attacker to do meaningful damage" principle doesn't really apply.

[tuhinadasgupta]

Reviewer: Tuhina Dasgupta Review Type: Critical

Problem:
Real-time systems are connected to the Internet, which makes them a clear target for cyber attacks. These systems tend to be involved with the physical world and if compromised can seriously impact their surroundings.

Importance:
The term Real-Time Internet-of-Things is defined to be a subset of IoT; these systems are more vulnerable to attack because being real-time means the network connectivity has be better and the property levels leave the system vulnerable to confidential info being exploited. The paper suggests several solutions, both hardware and software such as SecureCore and TaskShuffler.

Questions:

1. Given the fact that real-time involves memory-constraints, how is SecureCore feasible since it uses expensive algorithms (clustering)?
2. How does TaskShuffler fix the issue of side-channel attacks?
3. Is re-setting (on/off) really the best way to prevent overhead for ReSecure?

Critiques:
-ScheduLeak isn't covered in enough depth in my opinion. Would love for there to be more in-depth coverage -I wish SDN being adapted for real-time systems was explained in more depth as well

[ericwendt]

Reviewer: Eric Wendt Review Type: Comprehension

Problem being solved With many real-time time systems needing to react quickly with sensor stimuli, security vulnerabilities are abundant. This paper aims to highlight some of these issues, as well as explore some approaches to mitigating them.

Contributions The first notable contribution to this paper was the brief discussion of possible attacks people can use on an RT-IoT device. This section covers topics like code-injection to the famous DoS attack. The most interesting item to me was the side-channel attack. This is something that seems so far out that I hadn't even considered it. The paper describes this as an exploit in one of the system's side-channels that an attacker can use to find operational information such as power consumption traces, memory access time, etc. Another contribution to this paper was the discussion about schedule randomization. This is to help prevent against scheduling attacks that result from the deterministic nature of scheduling algorithms. This paper promotes TaskShuffler, which has configurable options to randomizing processes. I think this is a decent approach to this type of attack, though I do not know how effective it is.

Questions

• How are things like memory access times found by attackers? I know every system is different, but I can't imagine information like this is readily available.
• Some more measurements based on these scheduling practices would be helpful. Is there an optimal range of randomness vs. deadline meeting that has worked best?
• The idea of loading fresh images of applications seems extreme. Can a single core processor do this in a timely manner?

[huachuan]

Reviewer: Huachuan Wang Review Type: Comprehensive

Overview

Recent developments and new functionality require real-time embedded devices to be connected to the Internet. This gives rise to the real-time Internet-of-things that promises a better user experience through stronger connectivity and efficient use of next-generation embedded devices. This paper states that real-time Internet-of-things is increasingly becoming targets for cyber-attacks, which is exacerbated by this increased connectivity. This paper provides a comprehensive summary of the context of real-time Internet-of-things security.

Contribution

This paper aims to raise the awareness of real-time security and bridge missing gaps in the current IoT context, which is securing the IoT systems with real-time constraints. The techniques and methodology from hardware-assisted security to scheduler-level as well as those for legacy systems are presented. The designers of the systems and research community will now be able to integrate and develop upon these frameworks required to secure safety-critical RT-IoT systems.

Questions

1. TaskShuffler can implement randomization schemes. Why the dummy task executed by an RTOS when other real-time tasks are not running at each scheduling point can eliminate the periodicity of busy intervals?

2. Contego framework allows the security tasks to execute in different modes, how is the better responsiveness and effectiveness of monitoring is provided.

[zacharied]

Reviewer: Zach Day Review type: Comprehension

Problem

This paper describes the current state of security in real-time IoT systems, including the pitfalls that come with being an internet-connected RT device, attack methodologies on RT devices, and the security techniques they utilize to counter these attacks.

Important areas

Real-time systems have become an interesting subset of IoT devices due to the unique constraints associated with their processing and communications, which themselves present new security challenges. Consideration of these aspects becomes especially important when you consider that many real-time systems operate in safety-critical domains, such as vehicles, weaponry, and heavy machinery.

Questions

• They cite an advantage of SecureCore being that only the trusted core module has to be implemented on the system; no architectural changes are required. However, with the other design constraint of SecureCore being that applications have to restart frequently, does the frequent restarting not introduce another (software-level) architectural constraint?

• TaskShuffler is an algorithm that can rearrange scheduled tasks while avoiding priority inversions. However, if one task is higher-priority than the others, then it will have to always be executed at the start of the hyper-period. If the attacker had sufficient knowledge of the system, would they not be able to calculate the hyper-period rate and use that to figure out the execution moment of the highest-priority task?

[samfrey99]

Reviewer: Sam Frey Review Type: Comprehension

Problem: Security for realtime IoT systems is often more challenging that for standard IoT systems due to the immediacy required for realtime computation. Realtime IoT devices can pose a much greater risk if compromised, and they must be protected as such.

Important Areas: The authors first provide an overview about realtime IoT devices before continuing on to present a variety of potential attack types such as code injection, side-channelling, and DOS attacks. The authors then propose various hardware and software security solutions to secure realtime IoT devices from these attacks.

Questions:

• I'm a bit confused by the restart protocol in section 4.1.4. Of course, reloading the OS is a great way to insure that execution on a clean codebase, but that takes time to do. How is this feasible within the time constraints of RT-IoT?
• Regarding the noleak constraint in section 4.2.1, how does the scheduler actually provide a guarantee that no forbidden information is shared? The paper is vague here.

[rachellkm]

Reviewer: Rachell Kim Review Type: Critical

Problem Being Solved:

The rise of internet connectivity in embedded systems with real-time requirements pose new security threats and challenges. The high risk nature of many real-time embedded systems that control physical systems make cyber-security more necessary in system design.

Main Contribution:

This paper discusses and summarizes the various properties, constraints, and security threats to real-time IoT (RT-IoT) systems. Moreover, the authors propose a few solutions such as the Simplex-based frameworks, SecureCore framework, and TaskShuffler to mitigate attacks.

Questions:

1. For the Simplex and SecureCore frameworks, how does simply monitoring untrusted entities that have been compromised guarantee that the overall system is physically safe? Or are they meant for attack detection only?
2. What would be the impact on total operational time with the ReSecure method? Would this not reduce by some significant factor?

Critique:

1. I’m very confused as to how restarting a system “frequently enough” to mitigate software attacks would be considered an efficient and reasonable solution given the resource and timeliness constraints in RT-IoTs. In theory, maybe, but in practice?
2. A small evaluation section for each of the proposed solutions may have been a nice addition to this paper. I think it would have been helpful to see some performance metrics for some of these solutions.

[chandaweia]

Please add your feedback and reviews below.

@mjhegarty 1. Resecure will reset itself when the UAV reaches the unsafe zone and it will back to the applications when UAV returns to a predefined safe zone threshold, so it means that resetting the system needs to reach a specific zone and it’s important to finish resetting successfully in time. Therefore, I think the answer is no. @gkahl 1.Your consideration is right. I think resetting a system is feasible when the time of resetting is in the safety for IoT. @searri 2.Good question. According to my understanding, I think once the device is reset, then the attacker will lose control of the device in most instances. So it will take much time to recontrol the device. However, for the remote devices, such as remote control aircraft, your consideration is important for manager to prevent from attacking. @tuhinadasgupta 3.I think Resecure may be not the best way to prevent overhead, but it’s efficient for some devices. Because for some IoT devices, resetting needs low overhead and is also convenient way to prevent from attacking. @ericwendt 1.Great question. I will talk about it in class. @samfrey99 1.Great question, I will talk about it in class. @rachellkm 1.Great question, I will talk about it in class.

[themarcusyoung]

Reviewer: Marcus Young Review Type: Critical

Problem Being Solved:

Internet connectivity in real-time embedded systems (RTIoT) has been increasing, and this poses new security threats. These systems tend to be in the physical world, and can pose serious physical and cyber threats if compromised.

Main Contribution:

This paper introduced and summarizes the various properties, constraints, and security threats to real-time IoT (RT-IoT) systems. They propose Simplex-based frameworks, SecureCore framework, and TaskShuffler to mitigate attacks as solutions to some of the RT-IoT threats.

Questions: How do we know that the secure core in Figure 5. can be trusted? Can it be compromised?

Doesn't randomized scheduling interfere with the services of RTIoT devices?

Critique: They are providing some nice security abstractions here in this paper, but I would like to hear more about the overheads these security additions entail. Will RTIoT devices be able to deal wit these overheads and still function properly?

Its hard for me to find a direct use case for randomized scheduling. I feel like this will directly disable some RTIoT devices as scheduling is a key component in making a RTOS perform properly and as desired