How to enforce “read-only” to parameters with Secure Firmware + OEM Customization?

[sam_copter (Sahil Ahmed)]

Hello ArduPilot community,

Working on a type-certification for DGCA / NPNT compliance project (India) where auditors expect evidence for “firmware tamper avoidance” and an “authentication procedure to change flight parameters.”

Setup

• Autopilot: Cube Orange+ (CubeOrangePlus)

• Firmware: ArduCopter 4.6+

Goals

1. Firmware tamper resistance: ensure the controller runs only organization-approved firmware using secure bootloader + signed firmware.

2. Parameter tamper resistance: prevent field users from changing selected safety-critical parameters (make them effectively “read-only” in operational mode), while still allowing authorized service changes.

What’s clear from docs so far :

• ArduPilot Secure Firmware: once installed, only firmware signed by our keys should run.

• MAVLink2 signing can prevent unauthorized GCS from reading/writing parameters and sending commands on non‑USB serial ports unless they have the passkey.​

• MAVLink2 signing does not protect USB (USB connections are unaffected; a USB user can still modify parameters/disable signing/change passkey).​

• APJ Tools @READONLY is not usable for us because the docs say this capability was removed as of ArduPilot 4.5+.​

• OEM Customization is the recommended approach for productized builds, but the OEM page also notes read-only marking behavior changed in 4.5+.​

Questions (what we’re looking for) :

1. In ArduCopter 4.6+, what is the recommended way to block PARAM_SET for a subset of parameters (LOIT_SPEED, ANG_MAX, LOIT_ANG_MAX etc)?

2. Is there a supported pattern for a service mode vs operational mode, where parameter writes are rejected unless a service condition is met ?

3. Given USB bypasses MAVLink signing, what do OEMs typically present to auditors: purely physical controls (sealed bay + SOP), or is there an ArduPilot-side hook to restrict USB parameter writes too?​

4. What test evidence is considered “good enough” to demonstrate compliance (e.g., signed firmware rejection test + param-tamper attempt logs)?

References used :

• Secure firmware (signed bootloader + signed firmware): https://ardupilot.org/dev/docs/secure-firmware.html

• OEM customization workflow + 4.5+ note: **https://ardupilot.org/copter/docs/common-oem-customizations.html**​

• MAVLink2 signing + USB limitation: **https://ardupilot.org/copter/docs/common-MAVLink2-signing.html**​

• APJ Tools removal note (4.5+): **https://ardupilot.org/dev/docs/apjtools-intro.html**​

Thanks in advance

[LupusTheCanine]

@sam_copter

In ArduCopter 4.6+, what is the recommended way to block PARAM_SET for a subset of parameters (LOIT_SPEED, ANG_MAX, LOIT_ANG_MAX etc)?

Lua script, example of one is provided in the scripting library directory (IIRC in examples though it may be in applets).

@sam_copter

Is there a supported pattern for a service mode vs operational mode, where parameter writes are rejected unless a service condition is met ?

Could be implemented as a part of the aforementioned script.

@sam_copter

Given USB bypasses MAVLink signing, what do OEMs typically present to auditors: purely physical controls (sealed bay + SOP), or is there an ArduPilot-side hook to restrict USB parameter writes too?

The script works regardless of MAVLink signing configuration.

@sam_copter

What test evidence is considered “good enough” to demonstrate compliance (e.g., signed firmware rejection test + param-tamper attempt logs)?

Whatever pleases DGCA/NPNT, at a minimum you should demonstrate that unsigned and incorrectly signed commands are rejected and correctly signed commands are accepted. Same for parameter sets with correct/incorrect values.

Other than the script Ardupilot doesn’t offer much protection against malicious users other than locking down the DFU when using signed bootloader. Malicious user can somewhat reasonably replace the FC or MCU.

[sam_copter (Sahil Ahmed)]

Thanks for the info, Is there any recommended best practice for making sure the script itself can’t be removed/disabled by a field user (e.g., where does the script will reside (external storage etc))?