OTA/RF threat model : from remote exposure to persistent unavailability in embedded systems

1. From Note 01 to a testable question

Note 01 establishes the project's vocabulary and general scope: connected embedded systems, OTA mechanisms, radio interfaces, persistent states and resilience [P1]. The programme page organises these matters around observability, data fusion, local classification, graduated response and portability [P2]. This note turns that framing into objects that can be described before a test, observed during it and assessed against criteria announced in advance.

The question at this stage is: what conditions and evidence would link a remote interaction to persistent unavailability, and then demonstrate a return to reliable operation within a defined scope? This question precedes algorithm selection. A model that recognises a change in load does not, by that ability alone, demonstrate that it detects firmware compromise.

The model draws on the cited sources to define the mechanisms under study and proposes qualification criteria specific to this project. Test-bench evaluation will compare those criteria with the behaviour of an identified configuration. Mechanisms described in vendor documentation and properties observed experimentally therefore represent distinct levels of knowledge.

2. Define the system and service before qualifying their loss

2.1. Availability relative to a function

The system under study comprises the device, its essential software components and the dependencies required by the selected service. For a gateway, that service might be forwarding authenticated measurements; for a flight controller, maintaining a specified control function in simulation; for a mobile platform, running a defined test service. The choice must be narrow enough to make failure observable. “The system works” is not a measurement criterion.

Each protocol will therefore define an experimental service contract: expected function, reference inputs, acceptable outputs, maximum delay, operational safety conditions and authorised dependencies. Let A(t) denote satisfaction of that contract at time t. A network response or successful boot is useful evidence but does not alone prove that the service is delivered correctly. Conversely, losing contact with the observer does not prove that the device has stopped.

2.2. Persistent state is not necessarily compromised

For observation, persistent state is divided into four sets: boot code and firmware; configuration and critical data; trust elements and version policies; and resources needed for recovery. This decomposition is proposed for the project. It does not assume that every set can be instrumented or modified on every platform.

A persistent write can be entirely legitimate. An authorised update changes software durably; a saved parameter can survive a reboot without degrading the service. The protocol must seek a change relevant to the effect under study, rather than treating every hash difference as a compromise. Volatile areas, logs and naturally changing data must be distinguished from artefacts expected to remain stable or have a specified version.

2.3. Long duration alone does not define PDoS

The PDoS literature addresses lasting, sometimes irreversible, harm to software or hardware [S1]. The project's initial scope is narrower: unavailability associated with a software or configuration change that persists after the initiating action ends and is not removed by the ordinary recovery mechanisms defined for the test environment. This is a working operational definition, not a new universal definition.

Exposure duration must be separated from effect persistence. A service blocked throughout an ongoing disturbance has not, on that basis alone, suffered a persistent effect. Conversely, a brief action can leave a configuration durably incompatible with expected operation. The causal question concerns what remains in the system once the action has ceased.

3. Qualify persistence and recovery

3.1. Record three dimensions separately

The proposed qualification rests on three dimensions: relevant persistent state, satisfaction of the service contract and the level of recovery required. They must be documented separately. A changed configuration without service loss is not PDoS within this scope. Service loss without sufficient evidence about state remains unavailability of undetermined cause.

An effect compatible with the PDoS scope studied here requires a documented relevant alteration; a supported causal link to unavailability; persistence of that unavailability after the disturbance stops; and failure of the ordinary recovery steps specified in the protocol. In simulation, this remains qualification of a simulated effect. Calling it an observed attack on a device additionally requires establishing the adversarial path and its preconditions, not merely producing the effect.

An actor's identity or hostile intent cannot be inferred from a power spike or repeated restarts. On a test bench, the scenario introduced by the experimenter supplies contextual information; an operational detector may not have it. Experimental ground truth and the knowledge available to the detector must remain distinct.

3.2. Proposed recovery categories

RC0–RC3 and INDET describe recovery within the protocol’s scope. This operational classification is distinct from a severity scale and from the programme’s graduated-response levels.

Ordinary recovery mechanisms are defined before testing: authorised restart, documented automatic switchover or another procedure integral to the test environment. Successful A/B switchover belongs in this category when it is planned behaviour. Android’s documented A/B mechanisms aim, among other things, to preserve a bootable path during an update; their actual availability must be checked on the device studied [S5].

Observation windows will be justified by normal test-environment behaviour and service requirements. No universal duration threshold is set here. A test stopped for safety reasons will be recorded as such; it will not automatically become evidence that recovery is impossible. Recovery times not fully observed will be reported as censored observations.

4. Assets and trust boundaries

4.1. Assets to consider

Protection covers the service, components needed to boot it and restoration resources. NIST SP 800-193 structures firmware resilience around protection, detection and recovery, distinguishing the associated roots and chains of trust [S2]. These functions structure the asset analysis below.

4.2. Where authorisation must be checked

Boundaries separate trust, not necessarily physical devices. A system may carry an image over an encrypted link and still need to decide whether that image is authorised for installation. Secure distribution models such as Uptane separate roles and trusted metadata to address different compromise cases [S3].

A scenario may concern only some of these boundaries. An inconsistent configuration can affect the service without changing the bootloader. The model must nevertheless keep each transition consistent with the selected adversary capabilities: a write privilege required by a mechanism must be explicit among its preconditions.

5. Adversary capabilities and the role of radio communications

5.1. Distinct profiles, without implicit accumulation

Four profiles are proposed. A1, an unauthenticated remote actor, can reach an exposed interface without an account. A2, the holder of a compromised maintenance account, has only the rights actually attached to it. A3, an actor controlling a distribution component, controls that component and only the keys explicitly assumed compromised. A4, an actor already holding local privileges on the device, represents a post-compromise state; it does not demonstrate an initial remote access path.

The right to install an image, the ability to produce a valid signature, direct storage-write access and control of a server are not equivalent capabilities. Uptane explicitly addresses partial compromises and rollback or cross-component incompatibility threats. Its scope does not itself cover malicious creation of software nonetheless trusted by the production chain [S3]. Every additional capability must therefore appear among the scenario's preconditions.

5.2. OTA, RF and the vulnerable mechanism

OTA denotes a remote-update function here; RF is the radio bearer of an interaction. A complete scenario must distinguish the channel, the protocol or function used, the relevant control mechanism and the state reached. Poor radio availability can interrupt communication. Without an additional mechanism, it does not prove a durable firmware change.

For each radio scenario, three links must be supported: the interaction reaches the component of interest; that component authorises or undergoes a relevant transition; and that transition durably affects the service. Packet loss alone establishes neither of the last two links. Link disturbances will therefore first serve as controls for transient behaviour in a simulator or controlled communication environment.

MAVLink 2 documentation describes message authentication and timing checks but leaves some acceptance rules to implementations [S4]. The mere presence of the protocol does not establish that a controller accepts an unauthorised command or that a command reaches persistent storage. The actual software stack, version and configuration must be identified. The initial model excludes disruptive transmissions toward third-party systems and direct physical destruction.

6. Scenarios T01 to T05 and associated controls

6.1. Read scenarios as proposals

The five T01–T05 scenarios cover updating, version policy, commands and persistent configuration. They are at the experimental-design stage. The accompanying matrix specifies their preconditions, candidate signals, controls, interpretation criteria and links to RQ1–RQ5 and H1–H4.

T01 primarily characterises a protection barrier. Correct rejection is a protection outcome, not a successful PDoS attack. The absence of writing concerns relevant areas; a rejection log may legitimately be stored.

T02 distinguishes an update incident from an adversarial action capable of causing it. Accidental interruption is a control for comparing resulting states and recovery mechanisms. Studying an adversarial path requires separately characterising the ability to interrupt and its consequences. The initial evaluation uses reversible simulation.

T03 examines a policy stated before testing. A rollback authorised during maintenance cannot be classified as an attack solely because the version number decreases. Likewise, a correctly signed version is not necessarily functionally compatible with every system component.

T04 keeps separate unauthenticated commands, authenticated but unauthorised commands, and authorised commands inappropriate in context. Conflating them would obscure the control being evaluated. Safety also depends on system state: an acceptable response on a stationary simulator is not automatically acceptable in physical operation.

T05 prepares observation of persistence and restoration in an isolated test application. An inconsistent configuration provides a controlled case of service degradation. This model is limited to the mechanisms represented: it reproduces neither the boot chain nor the hardware protections of a commercial device, and does not establish an OTA/RF exploitation path.

6.2. Three essential controls

C00, normal operation, will characterise expected variation and ordinary recovery. C01, a benign load anomaly, will measure the risk of confusing resource variation with a hostile event. C02, interruption and restoration of a simulated link, will test the distinction among lost observation, service interruption and persistent alteration. Their assumed benign nature must be checked within the test environment; a control label does not remove the need to verify final state.

Where the test environment permits it, T05 will also be compared with a benign configuration error producing similar symptoms. That comparison separates the ability to detect degradation from the ability to attribute its cause. Identical symptoms may justify an availability or integrity alert without establishing malicious intent.

7. Build an observation that can be contradicted

7.1. Independent ground truth

The reference timeline will include, where observable, the start of the controlled action, the relevant persistent transition, the first service-contract violation, the end of the disturbance, the alert, the start of recovery and the verified return to service. Unobservable events will be declared unknown. They will not be reconstructed from the detector score that is itself under evaluation.

A separate observer may record the service contract and test actions. Separation alone does not make it infallible: its dependencies, clock and possible losses must be documented. A log from a component suspected of compromise must not be treated as independent proof of that component's integrity.

An alert’s earliness is assessed relative to an event defined in advance, such as the first breach of the service contract. Lead time is the difference between that event and the alert. It is interpretable only if it exceeds clock-synchronisation uncertainty. An alert after alteration but before service loss will be distinguished from one before alteration. Temporal qualification relies on transitions that can actually be observed.

7.2. Sources and blind spots

Software events may describe validations, errors, versions and transitions. Performance metrics describe resource use. Network observations characterise exchanges and availability. Physical measurements may be added if adequate instrumentation exists. This organisation is an experimental proposal; the incremental value of a source remains to be demonstrated.

Each source will be characterised by unit, frequency, time origin, resolution, losses, cost and trust dependencies. Direct measurements will be distinguished from estimates; CPU utilisation and energy consumption will be treated as different quantities. Because acquisition can change load or writes, its effect will be assessed with and without instrumentation where possible.

8. Link hypotheses to test conditions

RQ1–RQ5 and H1–H4 organise the proposed comparisons. RQ5 examines transferability between platforms. Decision thresholds and campaign size will be defined in the experimental protocol for each comparison.

H1 concerns an explicitly bounded class of scenarios: a case without an early signal contradicts a universal claim, but its meaning depends on the stated validity domain. H2 requires a relevant minimum gain, H3 a test-environment-specific resource budget, and H4 a joint assessment of restorations and undesirable effects. These criteria will be fixed before evaluation so that study objectives remain independent of result interpretation.

9. Minimal protocol and analysis criteria

9.1. Proposed sequence

Preparation begins by identifying a test environment, its owner, versions, tested function and dependencies. Before any disturbance, restoration must be tried and its outcome checked. The protocol then fixes the question, scenario, controls, primary measure, observation windows, repetitions and stopping conditions. Incomplete preparation leaves the scenario at documentary status.

Initial collection covers normal operation and benign controls. The controlled scenario follows, initially in observation-only mode. Conditions will be randomised or counterbalanced where possible to avoid confusing the scenario with test-environment drift. Each execution will be separated from the next by a verified return to the reference state. An autonomous-response campaign will be separate and begin only after recovery and safety constraints have been reviewed.

9.2. Evaluation unit and data

The protocol will state whether the decision unit is a window, event or session. Many windows from one run do not substitute for many independent runs. Training, validation and test partitions will be separated by session and, for some transfer questions, by device. Normalisation and feature selection will use training data only. The test set will be reserved for final evaluation of the selected configuration.

The positive class depends on the question: anomaly, persistent transition or service violation. It will not be renamed “PDoS attack” without the corresponding evidence. Files will also retain a provenance status: simulation, hardware test or authorised external capture. Raw data, transformations and exclusions will be tracked separately.

9.3. Proposed measures

Detection evaluation will report the confusion matrix, recall and precision for the defined class, false-positive rate, missed events and alert timeline. Metrics with zero denominators will be marked undefined. Control analysis will also measure alerts associated with session startup rather than the event of interest.

For recovery, time from restoration start to verified service return will be distinguished from total unavailability. The success rate will state its denominator; stopped tests and censored durations will be reported separately. Resource measures will at least cover accessible and relevant costs: memory, load, latency and artefact size. Energy remains unmeasured until appropriate equipment is available.

The analysis plan will justify repetitions using a pilot study, observed variability and desired precision. Uncertainty intervals will be calculated at the appropriate independence level, notably the session.

10. Apply the model to candidate platforms

10.1. Jetson Orin

Jetson Orin is envisaged as an embedded-Linux environment for service observation and collection preparation. Jetson Linux r36.5.2 documentation describes bootloader A/B redundancy [S6]. Evaluation will require identifying the exact model, software version, storage, enabled protections and recovery paths. Initial tests will use restorable test services before examining boot components.

10.2. Pixhawk and flight-control stack

Pixhawk names a hardware family; the running stack must be named separately. PX4 provides simulation environments, including software-in-the-loop, that can prepare some observations without a physical controller [S7]. Simulation can examine a validation policy or service transition. It does not establish real-memory resistance, hardware-bus timing or effective radio behaviour. Moving to a physical bench requires checks specific to hardware, peripherals and safe state.

10.3. Android

Android Verified Boot describes a verification chain and protection against certain rollbacks [S8]. A/B documentation describes, for relevant architectures, mechanisms for maintaining boot continuity during updates [S5]. Evaluation must identify the manufacturer, model, version, bootloader state and update scheme actually used. An unlocked device or a laboratory-modified image has a different trust model from a locked production device. That difference must be recorded rather than automatically equated.

11. Recovery, response and operational safety

An alert provides information; a response changes the system. The protocol must measure information quality and action consequences separately. A classifier score will not be treated as a reliable probability without calibration assessment. Decision thresholds and conditions will be determined on the data reserved for that purpose and fixed before testing.

Recovery targets a state whose required properties have been verified. A successful reboot can leave an inconsistent configuration; a delivered service can hide a return to a version that no longer satisfies trust policy. Final checks will therefore address properties in the service contract: function, accessible version or integrity, configuration consistency and continued availability of the recovery path.

Authorised actions depend on context. Isolating an interface, suspending an update and restoring configuration have different consequences. For a cyber-physical system, safe state will be defined with the relevant physical functions; it is not necessarily equivalent to shutting down the device. Test stopping criteria and authority for manual resumption will be fixed before execution. An unverifiable state will leave the conclusion open.

12. Validity, limitations and disclosure

The first validity threat is demonstrating only the behaviour programmed into a simulator. A simplified model can validate collection or analysis procedures, but its structure may make discrimination artificially easy. Conclusions will therefore specify which transitions were imposed and which were actually observed on equipment.

A second limitation is instrumentation: added privileges, enabled logs and external monitoring can change test-environment behaviour. A third is generalisation: the same processor family or protocol does not guarantee the same signals or recovery possibilities. A fourth is causality: failure symptoms and malicious-action symptoms can be identical. The project may produce useful degradation detection without resolving attribution.

Public disclosure covers the threat model, evaluation criteria and limits of interpretation. Data and operational test-bench details are subject to controlled access appropriate to their sensitivity.

13. Next milestone and transition conditions

The next stage combines review of the threat model with qualification of a first reversible environment. It comprises defining an observable function, checking scenario preconditions, trying a restoration procedure, and setting controls and analysis rules. Software versions and the operation timeline will be documented to support interpretation and reproduction of tests.

An initial simulated sequence may combine C00, C01 and C02, followed by a limited variant of T05. It will test service observation, persistence qualification and restoration verification. Moving to a physical device will then depend on the instrumentation and recovery capabilities of the selected platform.

Expected evidence at this stage is a coherent set: finalised protocol, test-environment record, timestamped traces, transformation description, limited conclusion and final-state check. Until those elements exist, scenarios remain proposed and hypotheses remain open. A properly documented negative or indeterminate conclusion will be retained as a useful outcome.

Bibliographic references

• [P1] Mamani Malam Goga, Abdoul Karim. Scientific foundations: connected critical embedded systems, OTA/RF surfaces and resilience to PDoS attacks. Note 01, version 0.1, September 2026. Read Note 01.
• [P2] Mamani Malam Goga, Abdoul Karim. Resilience of embedded systems against PDoS attacks. Programme overview.
• [S1] Abaimov, Stanislav. Understanding and Classifying Permanent Denial-of-Service Attacks. Preprint, version 1, 9 February 2024. Preprint text. Published version: Journal of Cybersecurity and Privacy, 4(2), 324–339, 2024. doi:10.3390/jcp4020016.
• [S2] Regenscheid, Andrew. Platform Firmware Resiliency Guidelines. NIST SP 800-193, May 2018. doi:10.6028/NIST.SP.800-193. PDF.
• [S3] Uptane Community. Uptane Standard for Design and Implementation, version 2.1.0, 2023. Version 2.1.0.
• [S4] MAVLink. Message Signing (Authentication). Technical documentation.
• [S5] Android Open Source Project. A/B (seamless) system updates. Technical documentation.
• [S6] NVIDIA. Jetson Linux Developer Guide: Update and Redundancy, r36.5.2 archive. Technical documentation.
• [S7] PX4. Simulation. Technical documentation.
• [S8] Android Open Source Project. Verified Boot. Technical documentation.

Associated appendices

Summary of the eight proposed scenarios and controls

The detailed scenario matrix (Excel) brings together the preconditions, observations and criteria for the five T01–T05 scenarios and three C00–C02 controls. A raw CSV version remains available for data analysis. The reading principles explain how scenarios, hypotheses and evaluation relate.

Programme overview · Note 01 · Request access to the workspace