Firmware code checksum, parameter checksum, and RSA firmware signing support for DGCA (India) compliance

General
1

Hello ArduPilot team,

I am working on UAV firmware compliance as per DGCA India requirements.
As part of certification, the Certifying Body (CB) has asked for clarification and evidence related to firmware integrity and signing.

I would like to understand whether ArduPilot already supports the following, or what the recommended approach would be.

1. Firmware code checksum

  • Is there a method in ArduPilot to calculate a checksum or hash (e.g., SHA-256) of the firmware code section?

  • Can this checksum be:

    • Generated at build time, and/or

    • Retrieved or verified at runtime (e.g., via MAVLink / GCS)?

2. Parameter / data checksum

  • Is there a way to calculate a checksum or hash over:

    • All parameters, or

    • A defined subset of critical / locked parameters?

  • Does ArduPilot expose any parameter checksum that can be fetched by a GCS while the vehicle is running?

3. GCS-side access

  • Is there any existing MAVLink message or API that exposes:

    • Firmware code checksum

    • Parameter / data checksum?

  • If not, what is the recommended method to implement this in a compliant way?

4. Signed firmware & integrity

  • When using signed firmware and locked parameters, does ArduPilot internally maintain:

    • A firmware integrity hash?

    • A parameter integrity hash?

  • If yes, are these values accessible for external verification or reporting?

5. Firmware signing algorithm (RSA vs ECDSA)

  • Does ArduPilot support RSA-based firmware signing?

  • If yes:

    • What RSA key sizes are supported (e.g., RSA-2048 / RSA-3072)?

  • If no:

    • Is RSA support planned, or is ECDSA the only supported signing mechanism?

Note:
Indian Certifying Authorities currently issue RSA-based Digital Signature Certificates (DSC).
ECDSA certificates are not provided, so RSA support is mandatory for DGCA compliance.

DGCA compliance requires:

  • Code checksum and data (parameter) checksum to be calculated separately

  • Firmware to be digitally signed using a CA-issued certificate

  • Submission of these values to the Certifying Body

  • A mechanism to verify that:

    • Firmware has not been modified

    • Critical parameters remain unchanged

This request is for regulatory compliance and certification purposes only.

2

Did you already read the secure firmware documentation? And watched the linked YouTube video?

3

Yes, I have gone through the secure firmware documentation and the linked video, and I have already implemented and validated ArduPilot secure boot on CubeOrange using the official signing workflow.

Specifically, I have:

  • Built and flashed the secure bootloader with embedded public keys using build_bootloaders.py

  • Built signed firmware using --signed-fw and make_secure_fw.py

  • Verified correct boot behavior (boot rejection on unsigned/tampered firmware)

  • Used MAVLink2 SECURE_COMMAND via MAVProxy for public key listing, removal, and update

  • Understood and implemented the full key management flow (bootloader ↔ firmware ↔ MAVLink)

So my question is not about how to enable secure boot or firmware signing, but about the following compliance-specific gaps:

  1. Signing algorithm

    • The current ArduPilot secure boot flow appears to use ECDSA (Monocypher).

    • Is there existing or planned support for RSA-based firmware signing?

    • This is important because Indian Certifying Authorities issue only RSA-based DSC certificates, and ECDSA certificates are not available.

  2. Checksums for compliance

    • Is there any existing mechanism in ArduPilot to:

      • Calculate and expose a firmware code checksum/hash (separately from the signature)?

      • Calculate and expose a parameter / data checksum, especially for locked / critical parameters?

    • Are any of these values available or intended to be exposed to the GCS side (e.g., via MAVLink)?

DGCA compliance explicitly requires separate code and data checksums to be submitted to the Certifying Body, in addition to firmware signing.

I’m trying to understand whether ArduPilot already supports this, or if the recommended approach is to implement this externally (e.g., build-time + runtime reporting).

Thanks for your guidance.

4

RSA is inferior to ECDSA. Request your issuing authority to get on with the times.

Parameters change all the time (ex. STAT_*, calibration parameters etc.) so having any sort of checksum over all of them is meaningless (at least for safety or traceability purposes).

5

Yes, there are a lot of read only parameters like ambient temperature or air pressure.

6

PS Ardupilot often doesn’t validate commanded parameters against (regulatory) limits. eg if you want to limit velocity to 19m/s (EU requirement for some classes) if the user issues do change speed command it will be obeyed (to physical limits) even if commanded velocity is higher than the limit.

Runtime checksum reporting proves nothing as it can be easily spoofed when running customized firmware. Ardupilot and MAVLink (except for signing support, which still requires secure key transfer method IIRC) are designed to operate in trusted environment and by trusted personnel. There is Lua script to lock down parameters.

IMHO if you want actual compliance you should work with the regulator from the fundamental goals of the regulations and the modifications to the code to enable compliance will be way more significant than adding checksum reporting.

By the way pretty much all of the regulatory hardware requirements can be trivially bypassed by swapping the Cube and adding compliance boilerplate so it pretends to comply :man_shrugging:. You would need to have a secure secret and use proof of knowledge to prevent spoofing the correct firmware.

1 Like
7

I agree that ECDSA is the better technical choice.

However, several Indian OEMs have already obtained DGCA approvals using ArduPilot-based systems, and their customized GCS displays firmware code and data checksums. If needed, I can share references to those OEMs privately.

I have also attempted signing firmware using RSA keys issued by Indian CAs, but the resulting firmware either became corrupted or failed to boot. This raises the question of whether these approved systems are:

Relying on procedural or external compliance mechanisms, or

Using custom verification logic, possibly implemented at the bootloader level.

I’m trying to understand whether such compliance-by-boilerplate is the currently accepted approach, or whether there is a more upstream-aligned solution within ArduPilot.

Regarding parameter checksums, I agree that checksumming all parameters is not meaningful.

To clarify, I am referring only to a small, explicitly defined subset of non-operational / safety-critical parameters that should remain unchanged after certification (not runtime or tuning parameters).

Is there any supported mechanism for this in ArduPilot, or is the expectation that this be handled externally (e.g., parameter snapshot + checksum)?

Overall, I’m not asking whether weak or spoofable mechanisms are possible — I’m aware they are.

My goal is to understand what is considered reasonable, defensible, and acceptable within the ArduPilot ecosystem given the current DGCA certification process.

If the conclusion is that:

ArduPilot will remain ECDSA-only, and

Code and data checksums are expected to be handled procedurally or outside the flight stack,

that clarity itself would be very helpful for aligning expectations with regulators and Certifying Bodies.

8

There is an existing firmware hash that is transmitted as STATUSTEXT upon GCS connection. You can see it in the Mission Planner title bar.

Beyond that, perhaps you could look into the firmware signing mechanism and modify it with an option for an encryption scheme that meets your governing body’s requirements. PRs welcome, of course.

1 Like
9

I would recommend you cooperate with DGCA and other Indian OEMs on AMC (acceptable means of compliance) for those requirements for Ardupilot equipped vehicles. Locked (read-only) parameters can’t be changed by the user so IMHO there shouldn’t be a need to compute a separate checksum for them.

You always could try a bit of GPL enforcement with other OEMs :smiley:. Legally you would need to get hardware from them to have the right to request source code as the GPL code sharing requirements apply only to users to whom they have distributed object code (binaries) (unless they publish their binaries online :smiling_face_with_horns:).

Only DGCA knows what is defensible :wink: (meets their interpretation of the regulations). For me any solution that meets GPLv3 requirements is fine, though PRs against the mainline would be really nice and avoid having three implementations of DGCA compliance (and possible license violations :sweat_smile:).

IMHO no static mean of firmware verification is capable of proving what firmware is present.
The only meaningful way of proving that firmware compiled by authorised party is present is to use some sort of proof of knowledge with key that will be destroyed if unsigned firmware is installed and can’t be easily recovered.

Right now, the system for tamperproof firmware (to the reasonable extent) relies on the signed bootloader with appropriate keys.