Test App to validate NPNT implementation


Hi @nihal @sidbh,

We started testing our application with NPNT Testing App and we have following observations for same:

  1. The valid permission artefact generated by the tool are not getting verified by our RFM.
    Just to give a better picture, our RFM is able to verify the PA downloaded from the DIGITAL SKY portal. Also if downloaded PermissionArtefact is tampered in any way our RFM is able to detect tampering by not verifying it.
  2. Flight Log verification is also not working for us. Flight Log is signed using RFM private key, while the generated signature and RFM public key gets merged with every flight log.


@nihal @cks123 I have not tried the app yet, but from responses, I believe that testing app is not generating signature via the process being executed on the server side currently. I think that’s not very difficult to achieve. If someone can fix it that’d be great, I will be trying out testing app after I am done with my current work on libnpnt, so I won’t get on it until then.
Also, the way I am thinking of maintaining chain of trust for Ardupilot’s implementation, is via secure boot and firmware generator. i.e. The key would be embedded into the firmware by a trusted machine, and loaded by trusted bootloader, it would be trusted machines responsibility to maintain chain of trust through to rootCA.


@cks123, can you provide some more details on the exact errors you are facing?

@sidbh, I will have a look at that in detail. @cks123, if you can help identifying the specific nature of difference in the implementation, it would be of great help to get everyone on to the same page


@cks123, and @sidbh

let’s track this issue here and close it ASAP.
@csk, provide details on the specific error message that causes signature verification failure please.


@cks123 @nihal @sidbh , I think the Signature verification works equivalently well for PAs generated by both, the server, and the Test App - worked the same for me. Also, I was able to work well with the Flight log authentication in the Test App. I don’t face any issue there, at least not right now.


@sachman, that’s great to hear.

@cks123, please post the specific issue you’re facing so it can be resolved



I have just updated the tool. You can check out teh repo for improved documentation and improved helper functions. Some examples are provided so you can test your implementation quickly.
changelog -

  • Additional Documentation
  • Unittest and sample cases
  • added Reset Button
  • Refactored Codebase for readability


Thanks for that.
One observation though, which can be an issue - the utility, which extracts out the FlightLog data for signature verification, converts double inverted quotes (") to single quotes (’), which will break the signature.



I am not sure where the NPNT test app might be going wrong, as @sidbh mentioned the signature generation(signing process) might be the cause. We had the similar issue in the libNPNT which @sidbh has recently resolved.
We just generated 6th permission artefact from the tool and tried to verify on our RFM and it was not verified. When I downloaded the PA from DigitalSky portal I could verify it.

Also thanks a lot for documentation and comments.


Actually certain params are missing in PA generated by the Test App, like MaxAltitude among other things. So I think your verification might be failing at those parsing checks, and not really signature verification. You may want to check this out.


@sachman We only verify signed data, we haven’t integrated parameter checking with xml verification. Also its weird how your code is able to verify it. If you are using libNPNT can you please check your version of code and revert.
@sidbh has recently updated the signature verification part of libNPNT.


Yes @cks123, I am aware of the changes that were done by @sidbh in order to correct the problem. The consequence of the ‘Urgent Bug’ in the libnpnt was that even invalid PAs were being reported as Valid.
Now, with the changes done to resolve the bug, the Valid permission Artefacts are getting verified fine, while the invalid ones are reported to be invalid.
The change, to correct the bug, was mostly identifying the exact data which gets signed, and which needs to be verified.
Since you are able to successfully verify the PA generated by server, It doesn’t strike me what could be going wrong with PAs by Test App - works well for me.

BTW, just to be sure, you are using the correct public key released by the Test App, right?
AND ALSO, the SHA algorithm that the Test App uses is SHA256, while the server is using SHA1. Do change that and check.


We are extracting the public key from the certificate which comes with Permission Artefact, do I have to use any other public key. If that’s the case then I think test app should generate the PA exactly like the server side, so that developers don’t have to maintain different code for testing tool and server side code.

Can we generate a similar PA(with all parameters) from NPNT testing tool as generated by DigitalSky portal.


I agree that there should be consistency here. What I would suggest is, since this is an open source, community’s app, we should ourselves discuss and make Pull Requests to the App instead of asking one particular developer too much.

Regarding the public key, extracting the public key from the certificate is fine. You can cross verify this by printing out the key that you are extracting, and then compare it with the dgca_public.pem present in the Test App’s repo.


I am only trying to highlight the issue I am facing.
Anyways I think you are right, the issue might be the Test app uses SHA256 while server side code uses SHA1 and we have developed our RFM code as per Server Side implementation.


Glad to know that it worked.


No @sachman, I haven’t tested it yet but it should be the SHA Algorithm.
Will have to make changes at few places in the test tool to make it use SHA1.
I will try it tomorrow.

Also @nihal has already added this as a issue on Github:


If the hashing method is at fault, it can be easily fixed. But that is missing the point.

But that would be a stop-gap solution as the Digital sky portal shouldn’t be using SHA1 in the first place.
The algorithm to be used is SHA256 with RSA 2048. SHA1 is not secure[1].

Even the RPAS guidance manual states that SAH256 should be used in sec 3.1.4.
This should be fixed in the digital sky portal side to work in the long term.
@sidbh, @charizard, Comments?

[1] https://www.zdnet.com/article/sha-1-collision-attacks-are-now-actually-practical-and-a-looming-danger/


I think SHA1 is part of the standard, that’s why its chosen to be like that. And I am in no way expert or even experienced in cryptography. But after thinking about it, my response is, you might be able to get a document with same signature, but that would certainly not be xml doc with same format. So, basically I think in our scenario it doesn’t actually matter, you might as well be 32 bit CRC value with the xml and you might be similarly secured.


Agree with Nihal. SHA-1 has been considered broken for a long time now. Apart from that, I think the XML signature generated by Digital Sky might fall under Digital Signature (End Entity) Rules 2015 (link). As per point 7, only the SHA-2 family(which includes SHA-256) is considered suitable for cryptographic hashing purposes.

If everyone agrees to change the algo to SHA-256, I might give a try at creating a PR for that in the Digital Sky API.

@sid @sidbh @sidhant @charizard