Pith. sign in

REVIEW 4 major objections 5 minor 47 references

Protecting Actuators in Safety-Critical IoT Systems from Control Spoofing Attacks

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Contego-TEE claims that routing every actuator command through an ARM TrustZone-resident invariant checker blocks control spoofing and actuation bursts even when the controlling tasks and operating system are fully compromised.

desk verdict The core idea is sound and the prototype works for the software path, but the paper overstates its security guarantee because it never shows the I2C controller is isolated from the normal world, leaving a direct-register bypass for a root adversary. read the letter →

arxiv 1908.09444 v1 pith:N5ZBNPDT submitted 2019-08-26 cs.CR cs.SYeess.SY

Monowar Hasan , Sibin Mohan This is my paper · ORCID
classification cs.CRcs.SYeess.SY
keywords controlspoofingattackstrustedexecutionenvironmentARMTrustZonereal-timeIoTsecurityinvariantcheckingrateactuatorprotectioncyber-physicalsystems
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to establish that the actuators of a real-time IoT system can be protected from control-spoofing attacks even when the software that drives them is fully compromised. Its framework, Contego-TEE, intercepts every actuation request in the kernel and forwards it to an invariant checker that runs inside the processor's trusted Secure World, so a hostile Normal World task or an attacker with root access cannot reach the physical hardware directly. The checker admits a command only if the sending task is permitted to use that actuator, the command matches the action implied by current sensor readings, and the request rate stays within a per-period budget; anything else is ignored or replaced by a predefined fail-safe command. On a commodity Raspberry Pi driving a COTS rover, the paper shows the rover completes its line-following mission under both a control-spoofing logic bomb and a DoS burst when Contego-TEE is on, while it deviates or speeds up when the framework is off. The defense is added below the application layer, so existing legacy control code runs unmodified, at a measured average overhead near 19.6 ms and worst-case overhead of 34.11 to 43.47 ms per control job in the case study.

What carries the argument

The load-bearing object is the invariant checker running in the Secure World of an ARM TrustZone processor, reached by an enclave client embedded in the Linux kernel through a Secure Monitor Call. The checker is driven by three rules: the access matrix (task $\tau_i$ may command actuator $\pi_k$ only if $a_{ik} = 1$); a state invariant $\text{CheckInv}(\tau_i, \pi_k)$ that reads the sensor state $S(t)$ and allows command $x_{ik}^t$ only if it is the unique command the state implies (in the rover experiment, the invariants map the line-sensor reading to exactly one of turn-left, turn-right, or go-straight at a fixed speed); and a rate-control rule $\Delta_{ik}(w) < \hat{\theta}_{ik}$ that ignores further requests once a task exceeds its design-time actuation budget within a window $w \in [0, T_i]$. On a violation the framework either ignores the command, letting the actuator hold its last good setting, or substitutes a predetermined fail-safe command. The framework's schedulability test absorbs the checker's added execution time into a worst-case response-time bound, $R_i^{TEE} = C_i^{TEE} + B_i^{TEE} + \sum_{\tau_h \in hp(\tau_i)} \lceil r_i / T_h \rceil C_h^{TEE} \le D_i$, so engineers can tell at design time whether a control loop can afford the protection.

What would settle it

Spoof the rover's line sensor so its reading stays inside the straight-ahead band $[-\theta, \theta]$ while the rover is actually off the line, then send a fwd() command: if Contego-TEE approves it and the rover keeps drifting, the state-invariant defense fails. Alternatively, fire a DoS burst whose request arrivals stay just below the design-time budget $\hat{\theta}_{ik}$ per window $T_i$, and check whether the actuator still receives more commands than the design allows.

Watch

Extended reading notes

Core claim

The central claim is that Contego-TEE makes false actuation impossible even when the controlling software is hostile: because every actuator command is routed through the processor's Secure World, a compromised Normal World task — even one with root privileges — cannot send arbitrary signals to the physical plant. The paper grounds this in the TrustZone hardware boundary, enforced by a kernel-level enclave client that traps each actuation request and switches to the Secure World, where the invariant checker validates the command against three things: the task's permission matrix entry, a state invariant that requires the command to be the one implied by current sensor readings, and a rate-control rule that bounds the number of actuation requests inside the task period. Valid commands pass through; invalid ones are ignored, letting the actuator hold its last good setting, or replaced with a predetermined fail-safe command. In the rover case study the same control code with the framework switched off deviates under a spoofing logic bomb and accelerates under a DoS burst, while with Contego-TEE enabled it follows the line at steady speed; the measured worst-case overhead of 34.11 to 43.47 ms per job, the authors argue, is acceptable for 15 Hz or slower controllers.

Load-bearing premise

The load-bearing premise is that the handwritten safety rules are complete and correct: the authors derive the rover invariants by manually inspecting the vendor's control code (Section 4.2.1), so any malicious command the rules fail to exclude will be approved by the trusted checker no matter how well the TEE isolates it.

Editorial extensions

If this is right

  • Even a root-level compromise of the real-time control stack cannot inject an actuation command that violates the handwritten state invariants or the per-period rate budget.
  • Legacy COTS control code runs unmodified, because the protection lives in the kernel and secure world rather than in application logic.
  • The design-time schedulability test, which folds invariant-checking overhead into the worst-case response time, lets an integrator decide before deployment whether a given control loop can absorb the added delay.
  • For dynamic vehicles the fail-safe response converts an attack into a benign mission hold, keeping the rover on its line instead of stalling or crashing.
  • Because the checker sits behind the TrustZone hardware boundary, the guarantee holds against software-only adversaries, which the paper's model explicitly scopes to exclude physical access.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural extension the paper leaves implicit is automated extraction of invariants from control code or from sensor-actuator traces, which would replace the manual specification step and make the security guarantee measurable rather than dependent on the engineer's care.
  • Because the checker trusts the sensor readings it validates against, a sensor-spoofing adversary — outside the paper's model — could drive the system into a state where a malicious command satisfies the invariants; validating sensor provenance is the next attack surface.
  • The rate-control budget is windowed by the task period, so an adversary who spaces actuation requests just under the threshold per window might evade detection while still saturating the actuator; testing sub-period request distributions would probe this boundary.
  • The reported overhead of 19.55 to 43.47 ms across average and worst cases is tied to this kernel and its OP-TEE world-switch path, so a batched or hardware-accelerated secure-world call interface could plausibly push the usable control-loop frequency above 15 Hz on the same hardware.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes Contego-TEE, a framework that uses ARM TrustZone to protect actuators in real-time IoT systems from control spoofing attacks. The design places an invariant checker in the secure world and an enclave client in the normal-world kernel that traps actuation requests (via SMC) and validates them against state-dependent and rate-control rules before they reach the actuator through I2C. A schedulability analysis is given to guarantee timing. The authors implement a prototype on a Raspberry Pi 3 with OP-TEE and demonstrate it on a GoPiGo2 rover, showing that the rover continues its line-following mission under a control spoofing attack and a DoS attack when Contego-TEE is enabled, while it deviates or speeds up when the framework is disabled.

Significance. If the security claim holds, Contego-TEE offers a practical, application-transparent way to retrofit COTS IoT devices with TEE-based actuation protection, and the open-source implementation would be a useful community artifact. The overhead measurements (roughly 19-43 ms added execution time) provide a concrete data point for feasibility. However, the central guarantee is contingent on hardware-level isolation of the peripheral controller, which is not demonstrated, and the correctness of the manually derived invariants is not validated. The work is a proof-of-concept with a positive demonstration, but the current evidence does not fully support the stated security claim for the paper's own adversary model.

major comments (4)
  1. [3.1, 4.1] The central claim that a compromised normal-world task cannot send false signals to the actuators is not established for the stated adversary model because the implementation intercepts only the kernel I2C character-device driver (i2cdev_fops in i2c-dev.c). The paper does not show that the I2C controller itself is isolated from the normal world via TrustZone peripheral protection (e.g., TZASC/TZPC or device-tree configuration). Given Section 2.3 explicitly grants the attacker root privileges in the normal world, a root adversary could write directly to the memory-mapped I2C controller registers (e.g., via /dev/mem or a kernel module) and bypass the invariant checker entirely, contrary to the claim in Section 3.1 that Contego-TEE 'breaks the bridge' between the peripheral subsystem and the hardware. The authors must either provide evidence of hardware-level isolation of the I2C controller or restrict the adversary model to exclude direct peripheral register access.
  2. [4.2.1] The security guarantee depends on the correctness and completeness of the manually derived invariant conditions. The paper states, 'We manually inspected the vendor-provided control code and translated them into invariant conditions,' but it provides no procedure, formalism, or test evidence that these invariants cover all malicious commands. For example, an attacker could send a command that satisfies INV1-3 (e.g., a st_sp value within the allowed range but not the design-time-desired value) yet still causes unsafe or unexpected behavior. The evaluation does not test invariant completeness or robustness under adversarial command variations; a single attack payload is shown. This limitation should be explicitly scoped or addressed with adversarial/random command generation tests.
  3. [4.2] The security behavior results in Fig. 4 appear to be based on a single run per attack scenario, with no error bars, repeated trials, or statistical summary. In contrast, the overhead results in Fig. 5 report data from 10,000 trials. This asymmetry limits confidence that the observed protection is not an artifact of the specific injected logic bomb. The authors should report multiple runs and variability for the security experiments, or clearly state that the figures are representative single-run illustrations.
  4. [Appendix] The schedulability analysis is presented as a design-time guarantee, but the paper does not experimentally validate that the prototype meets the predicted worst-case response times under load. The authors do not compare measured execution times against the R_TEE_i bound, nor do they demonstrate a taskset that is schedulable only with the additional overhead. The statement that Contego-TEE 'can be used with 15 Hz (or slower) controllers' is supported only by a simple rate calculation, not by a schedulability experiment. Adding a measurement of worst-case response times with the framework active would strengthen the timing claim.
minor comments (5)
  1. [3.1, Figure 3] The circled numbers (1 through 8) in Figure 3 are not explained in the caption or the text; adding a legend or explicit references in the prose would make the architecture significantly easier to follow.
  2. [Introduction] There is a typo in the sentence 'We use ARM TrustZone as a TEE and implemement our solution' where 'implemement' should be 'implement'.
  3. [2.3] The adversary model grants root privileges in the normal world but does not explicitly state whether the attacker is assumed to be able to modify the TrustZone configuration or access secure-world memory; making this explicit would help clarify the security boundary.
  4. [4.2.1] The invariant symbols (theta, delta1, delta2, btheta) are introduced in prose but not defined in a dedicated notation table; a short table or list would improve readability and reproducibility.
  5. [5] The comparison with PROTC and other related work is qualitative only; providing overhead or security-property comparisons in a table would make the novelty claim more concrete.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Contego-TEE's protection claim is conditional on explicitly stated invariants, and its schedulability analysis is standard response-time analysis.

full rationale

The paper does not derive its security result from a parameter fitted to the same data, nor does it import a uniqueness claim from the authors' prior work. The core mechanism is a TEE-enforced invariant checker; the invariant conditions are stated as design inputs, e.g., 'We manually inspected the vendor-provided control code and translated them into invariant conditions' (§4.2.1). The security evaluation demonstrates that commands violating those hand-written invariants are blocked, which is an enforcement test, not a circular prediction. The schedulability argument is standard fixed-priority response-time analysis ('Our schedulability test is based on the fixed-priority response time analysis proposed in RT literature [13]', Appendix), with a blocking term for the secure-world checker; no equation reduces to its own output. The measured overheads are empirical. Authors' prior work is cited for background (e.g., [1], [38-40]) but is not load-bearing: no conclusion rests on an unverified self-citation. A possible hardware-isolation gap (e.g., direct register access to the I2C controller bypassing the modified driver) would be a correctness/security limitation, not a circularity, because the framework's stated guarantee assumes all actuation paths pass through the checker.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The central claim depends on the integrity of the TEE boundary, the correctness of manually specified invariants, and the validity of standard real-time scheduling assumptions. No new physical entities are introduced.

free parameters (2)
  • Invariant thresholds (θ, θ_WL, θ_WT, δ1, δ2) = θ=2500, δ1 and δ2 in [0,255] for the rover case study
    Hand-chosen design parameters for the specific demo; not fitted to data to make the central claim work, but they are required to define the invariant rules.
  • Rate control threshold bθ_ik = Not specified for the case study
    Design-time bound on the number of actuation requests per period; must be set for each actuator and task.
assumptions (3)
  • domain assumption The host OS and normal-world tasks can be compromised, but the TrustZone secure world cannot be compromised by software attacks.
    The adversary model in Section 2.3 allows root-level compromise of the NW; the whole scheme relies on TEE isolation.
  • domain assumption Tasks are periodic with known WCET, deadlines, and fixed-priority preemptive scheduling; total utilization is less than 1.
    The schedulability analysis in the Appendix uses standard response time analysis, which requires these real-time assumptions.
  • domain assumption Actuators are controlled via peripheral interfaces (e.g., I2C or SPI) that can be intercepted by a kernel-level dispatcher.
    The implementation modifies the I2C dev interface; the framework requires that the trusted code can mediate all actuator access.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Protecting Actuators in Safety-Critical IoT Systems from Control Spoofing Attacks." pith.science (2026). https://pith.science/paper/N5ZBNPDT

@misc{pith2026190809444,
  author       = {Pith},
  title        = {Pith review of: Protecting Actuators in Safety-Critical IoT Systems from Control Spoofing Attacks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/N5ZBNPDT}},
  note         = {Machine review of arXiv:1908.09444}
}
read the original abstract

In this paper, we propose a framework called Contego-TEE to secure Internet-of-Things (IoT) edge devices with timing requirements from control spoofing attacks where an adversary sends malicious control signals to the actuators. We use a trusted computing base available in commodity processors (such as ARM TrustZone) and propose an invariant checking mechanism to ensure the security and safety of the physical system. A working prototype of Contego-TEE was developed using embedded Linux kernel. We demonstrate the feasibility of our approach for a robotic vehicle running on an ARM-based platform.

Figures

Figures reproduced from arXiv: 1908.09444 by the authors.

Figure 1
Figure 1. Demonstration of a control spoofing attack on a [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. High-level schematic of a RT control system. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Overview of Contego-TEE system design (left) and high-level control flow of RT tasks in Contego-TEE (right). [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Illustration of Contego-TEE under (a) control spoofing and (b) DoS attacks. Contego-TEE prevents the sending of malicious commands to the motors and ensures that the rover moves at a steady speed. bwd() dec_speed() fwd() inc_speed() left() left_rot() right() right_rot(…
Figure 5
Figure 5. Figure 5: Runtime of rover control tasks with and without [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

47 extracted references · 47 canonical work pages

  1. [1]

    Securing real-time Internet-of-things,

    C.-Y. Chen, M. Hasan, and S. Mohan, “Securing real-time Internet-of-things, ” Sensors, vol. 18, no. 12, 2018

    work page 2018

  2. [2]

    Future of the Internet of things in mission critical applications,

    J. Westling, “Future of the Internet of things in mission critical applications, ” 2016

    work page 2016

  3. [3]

    W32. stuxnet dossier,

    N. Falliere, L. O. Murchu, and E. Chien, “W32. stuxnet dossier, ” White paper, Symantec Corp., Security Response , vol. 5, p. 6, 2011

    work page 2011

  4. [4]

    Recent results in computer security for medical devices,

    S. S. Clark and K. Fu, “Recent results in computer security for medical devices, ” in MobiHealth, 2011, pp. 111–118. 6

    work page 2011

  5. [5]

    Comprehensive experimental analyses of automotive attack surfaces,

    S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage, K. Koscher, A. Czeskis, F. Roesner, T. Kohnoet al., “Comprehensive experimental analyses of automotive attack surfaces, ” inUSENIX Sec. Symp., 2011

    work page 2011

  6. [6]

    I2C manual,

    “I2C manual, ” Philips Semiconductors, 2003. [Online]. Available: https: //tinyurl.com/i2c-manual

    work page 2003

  7. [7]

    Raspberry Pi,

    “Raspberry Pi, ” https://www.raspberrypi.org/products/raspberry-pi-3-model-b/

    work page

  8. [8]

    Robot arm control,

    “Robot arm control, ” https://github.com/tutRPi/6DOF-Robot-Arm

    work page

Show all 47 references
  1. [9]

    Trusted execution environment: What it is, and what it is not,

    M. Sabt, M. Achemlal, and A. Bouabdallah, “Trusted execution environment: What it is, and what it is not, ” inIEEE Trustcom/BigDataSE/ISPA, 2015, pp. 57–64

    2015

  2. [10]

    Demystifying ARM TrustZone: A comprehensive survey,

    S. Pinto and N. Santos, “Demystifying ARM TrustZone: A comprehensive survey, ” ACM CSUR, vol. 51, no. 6, p. 130, 2019

    2019

  3. [11]

    Intel SGX Explained,

    V. Costan and S. Devadas, “Intel SGX Explained, ”IACR Crypt. ePrint Arch., no. 086, pp. 1–118, 2016

    2016

  4. [12]

    Scheduling algorithms for multiprogramming in a hard-real-time environment,

    C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogramming in a hard-real-time environment, ”JACM, vol. 20, no. 1, pp. 46–61, 1973

    1973

  5. [13]

    Applying new scheduling theory to static priority pre-emptive scheduling,

    N. Audsley, A. Burns, M. Richardson, K. Tindell, and A. J. Wellings, “Applying new scheduling theory to static priority pre-emptive scheduling, ” SE Journal, vol. 8, no. 5, pp. 284–292, 1993

    1993

  6. [14]

    Schedulability analysis of periodic fixed priority systems,

    E. Bini and G. C. Buttazzo, “Schedulability analysis of periodic fixed priority systems, ”IEEE Trans. on Comp., vol. 53, no. 11, pp. 1462–1473, 2004

    2004

  7. [15]

    TEE client API specification v1.0,

    “TEE client API specification v1.0, ” https://globalplatform.org/specs-library/ tee-client-api-specification/

  8. [16]

    Alidrone: Enabling trustworthy proof-of-alibi for commercial drone compliance,

    T. Liu, A. Hojjati, A. Bates, and K. Nahrstedt, “Alidrone: Enabling trustworthy proof-of-alibi for commercial drone compliance, ” inIEEE ICDCS, 2018, pp. 841– 852

    2018

  9. [17]

    Systematically evaluating security and privacy for consumer IoT devices,

    F. Loi, A. Sivanathan, H. H. Gharakheili, A. Radford, and V. Sivaraman, “Systematically evaluating security and privacy for consumer IoT devices, ” in ACM IoTS&P, 2017, pp. 1–6

    2017

  10. [18]

    A generalized model for preventing information leakage in hard real-time systems,

    R. Pellizzoni, N. Paryab, M.-K. Yoon, S. Bak, S. Mohan, and R. B. Bobba, “A generalized model for preventing information leakage in hard real-time systems, ” in IEEE RTAS, 2015, pp. 271–282

    2015

  11. [19]

    Learning execution contexts from system call distribution for anomaly detection in smart embedded system,

    M.-K. Yoon, S. Mohan, J. Choi, M. Christodorescu, and L. Sha, “Learning execution contexts from system call distribution for anomaly detection in smart embedded system, ” inACM/IEEE IoTDI, 2017, pp. 191–196

    2017

  12. [20]

    Using simplicity to control complexity,

    L. Sha, “Using simplicity to control complexity, ”IEEE Software, vol. 18, no. 4, pp. 20–28, 2001

    2001

  13. [21]

    ORTEGA: An efficient and flexible online fault tolerance architecture for real-time control systems,

    X. Liu, Q. Wang, S. Gopalakrishnan, W. He, L. Sha, H. Ding, and K. Lee, “ORTEGA: An efficient and flexible online fault tolerance architecture for real-time control systems, ”IEEE T. on Ind. Inf. , vol. 4, no. 4, pp. 213–224, 2008

    2008

  14. [22]

    L1Simplex: Fault-tolerant control of cyber-physical systems,

    X. Wang, N. Hovakimyan, and L. Sha, “L1Simplex: Fault-tolerant control of cyber-physical systems, ” in2013 ACM/IEEE ICCPS, 2013, pp. 41–50

    2013

  15. [23]

    S3A: Secure system simplex architecture for enhanced security and robustness of cyber-physical systems,

    S. Mohan, S. Bak, E. Betti, H. Yun, L. Sha, and M. Caccamo, “S3A: Secure system simplex architecture for enhanced security and robustness of cyber-physical systems, ” inACM international conference on High confidence networked systems . ACM, 2013, pp. 65–74

    2013

  16. [24]

    ReSecure: A restart- based security protocol for tightly actuated hard real-time systems,

    F. Abdi, M. Hasan, S. Mohan, D. Agarwal, and M. Caccamo, “ReSecure: A restart- based security protocol for tightly actuated hard real-time systems, ” in IEEE CERTS, 2016, pp. 47–54

    2016

  17. [25]

    SecureCore: A multicore- based intrusion detection architecture for real-time embedded systems,

    M.-K. Yoon, S. Mohan, J. Choi, J.-E. Kim, and L. Sha, “SecureCore: A multicore- based intrusion detection architecture for real-time embedded systems, ” inIEEE RTAS, 2013, pp. 21–32

    2013

  18. [26]

    SPI block guide V04.01,

    “SPI block guide V04.01, ” Motorola Inc, 2004. [Online]. Available: https://tinyurl.com/spi-block

    2004

  19. [27]

    From design to invariants: Detecting attacks on cyber physical systems,

    S. Adepu and A. Mathur, “From design to invariants: Detecting attacks on cyber physical systems, ” inIEEE QRS-C, 2017, pp. 533–540

    2017

  20. [28]

    The worst-case execution-time problem—overview of methods and survey of tools,

    R. Wilhelm, J. Engblom, A. Ermedahl, N. Holsti, S. Thesing, D. Whalley, G. Bernat, C. Ferdinand, R. Heckmann, T. Mitra et al. , “The worst-case execution-time problem—overview of methods and survey of tools, ” ACM TECS, vol. 7, no. 3, p. 36, 2008

    2008

  21. [29]

    Orpheus: Enforcing cyber-physical execution semantics to defend against data-oriented attacks,

    L. Cheng, K. Tian, and D. D. Yao, “Orpheus: Enforcing cyber-physical execution semantics to defend against data-oriented attacks, ” in ACM ACSAC, 2017, pp. 315–326

    2017

  22. [30]

    VirtSense: Virtualize Sensing through ARM TrustZone on Internet-of-Things,

    R. Liu and M. Srivastava, “VirtSense: Virtualize Sensing through ARM TrustZone on Internet-of-Things, ” inACM SysTEX, 2018, pp. 2–7

    2018

  23. [31]

    PROTC: PROTeCting drone’s peripherals through ARM trustzone,

    R. Liu and M. Srivastava, “PROTC: PROTeCting drone’s peripherals through ARM trustzone, ” inACM DroNet, 2017, pp. 1–6

    2017

  24. [32]

    Open Portable Trusted Execution Environment,

    “Open Portable Trusted Execution Environment, ” https://www.op-tee.org/

  25. [33]

    Implementation code for Contego-TEE,

    “Implementation code for Contego-TEE, ” https://github.com/mnwrhsn/rt_ actuator_security

  26. [34]

    GoPiGo,

    “GoPiGo, ” https://github.com/DexterInd/GoPiGo

  27. [35]

    RoboADS: Anomaly detection against sensor and actuator misbehaviors in mobile robots,

    P. Guo, H. Kim, N. Virani, J. Xu, M. Zhu, and P. Liu, “RoboADS: Anomaly detection against sensor and actuator misbehaviors in mobile robots, ” inIEEE/IFIP DSN, 2018, pp. 574–585

    2018

  28. [36]

    Dexter Industries Sensors,

    “Dexter Industries Sensors, ” https://github.com/DexterInd/DI_Sensors

  29. [37]

    Detecting attacks against robotic vehicles: A control invariant approach,

    H. Choi, W.-C. Lee, Y. Aafer, F. Fei, Z. Tu, X. Zhang, D. Xu, and X. Xinyan, “Detecting attacks against robotic vehicles: A control invariant approach, ” in ACM CCS, 2018, pp. 801–816

    2018

  30. [38]

    Contego: An adaptive framework for integrating security tasks in real-time systems,

    M. Hasan, S. Mohan, R. Pellizzoni, and R. B. Bobba, “Contego: An adaptive framework for integrating security tasks in real-time systems, ” in Euromicro ECRTS, 2017, pp. 23:1–23:22

    2017

  31. [39]

    Exploring opportunistic execution for integrating security into legacy hard real-time systems,

    M. Hasan, S. Mohan, R. B. Bobba, and R. Pellizzoni, “Exploring opportunistic execution for integrating security into legacy hard real-time systems, ” inIEEE RTSS, 2016, pp. 123–134

    2016

  32. [40]

    A design-space exploration for allocating security tasks in multicore real-time systems,

    M. Hasan, S. Mohan, R. Pellizzoni, and R. B. Bobba, “A design-space exploration for allocating security tasks in multicore real-time systems, ” inDATE, 2018, pp. 225–230

    2018

  33. [41]

    Cross-layer retrofitting of UAVs against cyber-physical attacks,

    F. Fei, Z. Tu, R. Yu, T. Kim, X. Zhang, D. Xu, and X. Deng, “Cross-layer retrofitting of UAVs against cyber-physical attacks, ” inIEEE ICRA, 2018, pp. 550–557

    2018

  34. [42]

    Memory heat map: anomaly detection in real-time embedded systems using memory behavior,

    M.-K. Yoon, S. Mohan, J. Choi, and L. Sha, “Memory heat map: anomaly detection in real-time embedded systems using memory behavior, ” in ACM/EDAC/IEEE DAC, 2015, pp. 1–6

    2015

  35. [43]

    Guaranteed physical security with restart-based design for cyber-physical systems,

    F. Abdi, C.-Y. Chen, M. Hasan, S. Liu, S. Mohan, and M. Caccamo, “Guaranteed physical security with restart-based design for cyber-physical systems, ” in ACM/IEEE ICCPS, 2018, pp. 10–21

    2018

  36. [44]

    A survey on security and privacy issues in Internet-of-Things,

    Y. Yang, L. Wu, G. Yin, L. Li, and H. Zhao, “A survey on security and privacy issues in Internet-of-Things, ”IEEE IoT J., vol. 4, no. 5, pp. 1250–1258, 2017

    2017

  37. [45]

    Internet of Things: A survey on the security of IoT frameworks,

    M. Ammar, G. Russello, and B. Crispo, “Internet of Things: A survey on the security of IoT frameworks, ”Elsevier J. of Inf. Sec. & App. , vol. 38, pp. 8–27, 2018

    2018

  38. [46]

    Research on ARM TrustZone,

    W. Li, H. Chen, and H. Chen, “Research on ARM TrustZone, ”ACM GetMobile, vol. 22, no. 3, pp. 17–22, 2019

    2019

  39. [47]

    Finding response times in a real-time system,

    M. Joseph and P. Pandya, “Finding response times in a real-time system, ” The Comp. J., vol. 29, no. 5, pp. 390–395, 1986. APPENDIX Response Time Analysis for RT Tasks Our schedulability test is based on the fixed-priority response time analysis proposed in RT literature [13]....

    1986

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.