Planned Authentication support?

[kc2rxo]

Is there any plans to support the transmission of Authentication messages with data coming from either Mavlink or DroneCAN?

[BluemarkInnovations]

Yes and no. There is no exact timeline, but authentication messages should be implemented IMO. One of the reasons is that these messages are mandatory in some regions like Japan. I already have code that does this, see screenshot of : https://github.com/BluemarkInnovations/opendroneid_mavlink_tx_demo

But I did not have the time to merge this into ArduRemoteID yet.

[BluemarkInnovations]

I have implemented the first small step; add Auth definitions for DroneCAN dronecan/DSDL#40

[kc2rxo]

I have been experimenting with Authentication support (using MAVLink) and have run into what I think are some architectural issues. I have not written any working code but am working through the problem on paper and finding where code modification may be needed.

When using MAVLink the ODID_AUTH message is a single Authentication Page ¹. With my experience in Python with MAVLink all the fields of this message MUST be filled in, leading to some ambiguity in regards to what should be used for fields only found in Page 0 but forced to have a value for Pages 1 to 15.

The extends up into the firmware. Currently by my reading and understanding the code ingesting MAVLink is called every ~1ms (not really sure) and only holds a singular MAVLink ODID_AUTH message (when normally multiple, one for each page is sent). So the local data structure will only contain the final page ingested. Additionally the UAS_data structure is re-initialized every timing loop (~1ms?) clearing older data from all the elements including Authentication and refilled using this local MAVLink structure.

I am wondering if the MAVLink (and perhaps DroneCAN) structures for ODID should be more general in the data they carry. That is have the ODID_AUTH from MAVLink not contain data_page, increase the authentication_data array to a fixed size of 255 and add an additional_data array (fixed size of 255) and its associated additional_data_length (ADL, max of 255) field. This puts it on transmit modules (taking in MAVLink) to convert to multiple byte structures and receivers (taking in multiple byte structures) to convert to MAVLink.

I suspect that changing the MAVLink protocol is high intrusive and my proposal might be against the ethos of the project. However I wanted to raise it regardless as my preferred option with the current understanding.

We could just extend the local MAVLink structure in the firmware to support multiple pages (clearing/overwriting them as new Message Counters come in) but I wonder how the timing would work out to sync the firmware loops (reading in MAVLink, building Authentication and sending over transports while keeping persistent for Authentication data) and the MAVLink transmission loops (building MAVLink message and sending to firmware). Having another device required to externally sync with the transmit modules loop seems like a huge hurdle that could cause nasty bugs.

For those curious I plan on attempting to implement the example schedule here ² where the system needs to juggle sending 3 different types of Authentication (a static blob; DRIP Link over all medium, a dynamically attached signature object; DRIP Manifest or DRIP Wrapper over Bluetooth 4, and a dynamically detached signature; DRIP Wrapper in Message Packs).

First order is getting Authentication being sent in any capacity using standard means of obtaining the data (i.e. MAVLink).

Footnotes

1. https://mavlink.io/en/messages/common.html#OPEN_DRONE_ID_AUTHENTICATION ↩

2. https://www.ietf.org/archive/id/draft-ietf-drip-auth-46.html#appendix-B.2 ↩