Suggestion: implement an user access control system

Development Team
1

Hi,

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.

2

Mavlink 2.0 packet signing
and Mission planner config password protection.
AES data link encryption with RFD modems
It’s already there

3

hi Andras,

is the config password at application level? Or FC level? If it’s in the app, it’s almost useless.

4

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.

5

is the config password at application level? Or FC level? If it’s in the
app, it’s almost useless.

That depends on what you’re trying to accomplish.

Any dedicated user can screw their aircraft up if they feel the
inclination.

Absolutely locking out the user isn’t actually possible… so it’s a
matter of how high to make the speedbumps!

6

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

7

I agree with you ,and it is necessary to input an admin password (everytime).
Has this problem been solved and how to ?

8

hi colorfuljune,

as far as i know, nothing has been implemented on this side, yet

9

The 4.0 releases will have the ability to tag parameters as “read only”, so that a vendor can choose which parameters are exposed to user changes.

10

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???