When making commercial grade UAVs, it would be very useful to implement an user access control system to protects settings, and eventually access to navigation commands.
Main purpose is to make a veichle’s settings hidden to end user to avoid him to mess up things.
Some regulator authorities are beginning to ask to guarantee UAV configuration integrity before release of certain “permit to fly” documents.
Also, this function is very important to make sure an “attacker” could not connect to an open telemetry channel while flying and take over control of the legit/authenticated pilot/GS.
One simple method would be to just make saving settings after input a password/pin.
One more sophisticated one would be having an authentication method which could let configure different user levels similar to unix-like envroinments. It’d be very useful for commercial operations, to implement a “geo”-like limitation functions, but open to be customized to the actual local regulations by the admin, per-veichle or by any other policy.
One example:
Guest (optional): can fly but very limited height distance and no auto. Can configured also as no-operation allowed if not auth (so system is protected from airborne takeovers by telemetry channel)
Authenticated user: can fly any area and auto modes but cannot modify settings (or a subset of it). User has to input his password (one time).
Admin user: can do everything. have to input an admin password (everytime).
policies should be freely customized, of course.
Password could be saved encrypted into flash or onto SD card. Changing it would require physical access to the SD, so i think it’s quite safe to do so.
Well, if you use mavlink 2.0 packet signing, then your fc tied to the mission planner which has the right keys, application level password then makes a perfect sense.
what i’m trying to accomplish is a simple confguration protection for the end user of a commercial UAV.
It should work (deny config changes) if the user:
installs mission planner on a different computer than the one which has done primary config
installs QGroundControl or other GS software on a tablet then connects it
…etc
So that’s why i think it should be at FC level, because it should be resilient to GS sw changes
Hi development team I want my ardupilot pixhawk should have two types of users one admin which cqan control anything another user, which can have access to few things, how to achieve this???