UAV firmware update framework using TUF

[Suvasis Mukherjee]

hi,

My company, Dronomy.io, is planning on integration of The Update Framework (TUF) into the Pixhawk 4 (PX4)  (https://px4.io) firmware update process through UAVCAN v1 (Cyphal) (https://opencyphal.org) to enhance the security framework for the distribution and installation of firmware updates. UAVCAN's is a dependable communication protocol in aerospace and robotics without an intrinsic secure software update mechanism, as I understand, the introduction of TUF will embed a layer of security.  This layer will authenticate, authorize, and safeguard the firmware updates against tampering. There will be a TUF repository on a server designated for hosting the firmware updates.This setup will necessitate the generation of keys, assignment of roles such as Root, Targets, Snapshot, and Timestamp, and a robust management of these keys to preserve the system's integrity. 

Next step I would assume will include integrating TUF within the PX4 firmware's build and release cycle, ensuring that new firmware releases are authenticated and authorized before distribution. Modifications to the PX4 firmware will be required to accommodate TUF's security checks before firmware updates are applied. The UAVCAN protocol will be extended to facilitate the transmission of TUF metadata, necessitating enhancements in both PX4 firmware and ground station software to support this advanced update process. Let me know if my train of thought is in the right direction. Here are some diagrams:

[Trishank Kuppusamy]

Hey Suvasis, 

This is neat. Would you like to join our community meeting next time to discuss?

Thanks,

Trishank

Calendly | Doodle | GitHub | Google Calendar | LinkedIn

--
You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theupdateframew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/0db27215-7769-4a0d-b351-337291006ed1n%40googlegroups.com.

[Jussi Kukkonen]

Hi Suvasis, 

Forgot to respond to this one, sorry.

Your ideas seem quite reasonable but I will note that "integration of TUF" covers a very large variety of potential systems. The differences mostly revolve around signing -- who does it and when? Some questions that might help narrow things down:
* are you planning for every artifact (firmware) release to be approved (cryptographically signed) by humans or is this meant to be a fully automated system that trusts the output of a build machinery?
* Have you considered how root signing happens -- this is typically human operated even if the artifact signing is fully automated. 

The answers depend on what you are looking to get from deploying TUF. Possible goals could be:

• safety against attacks on firmware hosting -- you get this with mostly any TUF setup
• Ability to recover from incidents -- you typically get this if your root is managed by human signers
• safety against compromised release automation -- you get this if all artifact releases are approved by humans
• Fully automated releases -- can't  have human signers involved in artifact releases if this is the case

Some practical deployment paths you could explore:

• rstuf.org: automated artifact signing at scale, root managed by humans
• tuf-on-ci: all changes (including artifact releases) signed by humans
• roll your own: I would not recommend this but it would allow you to make decisions the two signing systems haven't made

The TUF slack channel is a decent place to discuss: https://cloud-native.slack.com/archives/C8NMD3QJ3 (the projects have their own channels as well)

Hope this helps,
Jussi

--

[Suvasis Mukherjee]

hi Jussi,

Sorry for the late reply.

This is for replicator UAV/UGV. I have shown some of the components in the attached diagram and it's not exhaustive. Also many of these components may have different vendors. So the firmware schedule can't be uniform, the ESCs are supplied by one vendor, the BMS and flight controller may be from NXP.  The ESC has a unsecured headless bootloader whereas NXP components may have a secure element (edgeLock SE050). The communication components from Doodlelabs.com may have completely different mechanisms. 

Currently, I am using UAVCAN v1(Cyphal), which abstracts the communication layer, so the hardware may use CAN/Serial/Ethernet/TSN/Wireless, Cyphal being an abstract layer, and it works seamlessly with minimal changes if the hardware is changed. Likewise, I am wondering if TUF offers any such abstraction leading to managing firmware updates in UAVs. There needs to be a firmware update management module. This module would handle downloading firmware compliant updates from a TUF compliant repository, verifying the cryptographic signatures and metadata provided by TUF and then applying updates securely.

Since, ESC and the flight controller have a RTOS and the onboard computer has a linux OS. So where can I have the firmware update management module and human intervention should happen at which level? There can be 100s or 1000s or replicator UAV/UGV? Human intervention at individual UAV/UGV level is not feasible. 

Thanks.

suvasis

[Jussi Kukkonen]

Hi suvasis,

The UAV-specific bits I can't possibly comment on but maybe this helps:

• TUF client libraries are comparable to HTTP libraries:
• from application POV the TUF library only takes care of downloading the firmware and verifying it's correctly signed (in the background there's TUF metadata downloads and parsing but that should be mostly hidden from the application)
• The TUF library is likely fairly easy to plug into an existing update system
• There are client implementations in multiple languages -- in the embedded use case (with language and framework limitations), the choice of client library may still be a problem
• the TUF library won't handle firmware management for you: choosing the correct firmware and version is still completely up to the application
• The more complicated part is still likely to be the TUF repository side as you will have to make the sort of policy decisions I referred to in the previous message

Jussi