AP_AerobridgeTrustedFlight: Add Aerobridge trusted flight subsystem

[rhythmize]

This subsystem enables token verification before arming the vehicle. The token needs to be valid at the time of arming and issued by a valid issuer (currently https://id.openskies.sh/) failing which the vehicle will not arm.

This is an opt-in feature and can be enabled by providing --trusted-flight-issuer (JWT token issuer) and --trusted-flight-root-certificate (Root Certificate to establish root of trust for token verification) during ./waf configure.

Helper scripts and README are added in Tools/AerobridgeTrustedFlight_tools/

[amilcarlucas]

Looks like the build size comparison did not work on this one:

Binary Name      Text [B]        Data [B]     BSS (B)        Total Flash Change [B] (%)      Flash Free After PR (B)
---------------  --------------  -----------  -------------  ----------------------------  -------------------------
antennatracker   -20 (-0.0015%)  0 (0.0000%)  -4 (-0.0015%)  -20 (-0.0015%)                                   608072
ardusub          -20 (-0.0013%)  0 (0.0000%)  -4 (-0.0015%)  -20 (-0.0013%)                                   385628
arducopter-heli  -20 (-0.0011%)  0 (0.0000%)  -4 (-0.0015%)  -20 (-0.0011%)                                   172008
blimp            -20 (-0.0015%)  0 (0.0000%)  -4 (-0.0015%)  -20 (-0.0015%)                                   664988
ardurover        -20 (-0.0012%)  0 (0.0000%)  -4 (-0.0015%)  -20 (-0.0012%)                                   342976
arduplane        -20 (-0.0011%)  0 (0.0000%)  -4 (-0.0015%)  -20 (-0.0011%)                                   192168
arducopter       -20 (-0.0011%)  0 (0.0000%)  -4 (-0.0015%)  -20 (-0.0011%)                                   1786[32]

[IamPete1]

I wonder if this should be a backend option for open drone ID, both can block arming. I guess this does not also have telemetry requirement?

[hrishiballal]

I wonder if this should be a backend option for open drone ID, both can block arming. I guess this does not also have telemetry requirement?

Actually, the telemetry etc. is normally submitted to the accompanying UTM product we develop: Flight Blender. This is normally deployed with Aerobridge, we use scripts like this to submit telemetry to Blender. Hardware ID / OpendroneID can be stored on the management server and checked / cross-checked before moving the token, in fact we do this, but this means that there is a dependency on the management server which we did not want to introduce at this stage. @IamPete1 , are you suggesting that we add it?

[rhythmize]

Hi @amilcarlucas, I'm not sure I correctly follow the build size comparison part you mentioned. Is it some mandatory check which is supposed to run on every new features? Do I need to whitelist something somewhere in the code? Can you please elaborate a bit on this? Thanks!

[amilcarlucas]

We usually take a look at the memory cost of every new added feature. Something went wrong your feature reduces memory cost.

[rhythmize]

Ah I see. Can you please share some links/ documentation with more info on this and how can I obtain this info locally? I'll try to investigate what's going wrong.

[rhythmize]

@amilcarlucas, I ran the pretty_diff_size script locally and got a diff of 4 bytes, which I can confirm is caused by refactoring here. Although I could not get the 20 bytes diff which we see in the ci build. Is it possible to force run the checks again to be sure, it was not something transient?

And re the memory costs about the new feature, it won't show up in the automated checks because this is an opt-in feature and is disabled by default. Additional details are added in the readme here

[rhythmize]

Current flash cost for this feature is additional ~119 KB Without trusted flight

With trusted flight