Test App to validate NPNT implementation


This app will be used as a common test platform for everyone to test their RFM/NPNT implementation.
Everything related to the APP will be discussed in this thread.


@sidbh @sidhant lets put a base version of the test App.


Also can we have a small documentation on following things:

  1. How the test application will sign permission artefact.
  2. How the test application will verify the log files and authenticate(if this is in application’s scope) the sender.
    (i.e. will the mechanism be similar to digital sky api implementation as posted on GitHub.)


@cks123 do you have a sample JSON Log file?


Hi Satya,

We are logging as mentioned in “Digital Sky - Technology Standards v1.0 - 22nd October 2018” document at Page No. 28, exactly same format.

For more information:


@Satya I have sent the request the devs to share the location of the Application source. Will share it soon.


A base version is okay for now just to start with. Ready to put some devs for further development.


Hello Everyone, you can find the tool here. Please have a look and test it out, raise issues if any.


@nihal , Thanks for your efforts.
Needed some clarifications on the app though:

  1. The DGCA public key that the vehicle should use to verify/authenticate the PA for the provisional certification process - should it be extracted from the sample DGCA certificate provided? Because, it seems the public key should be part of firmware, so the public key to be used for verification of PA has to be known before hand. Please let me know if I am wrong somewhere.
  2. The app also checks for wrong pilot pin - I thought the unawareness of Salt was a roadblock here? Also, as the app is auto-generating the PAs, against what Pilot Pin can it actually be verified?

@Satya @cks123 , what do you think?



  1. the repository contains a certificate and the corresponding public/private keypair that can be used for provisionaltetsing purposes. Do note that this will not be the one used during deployment.

  2. The Pilot PIN is currently being encrypted by the Public key of the RPAS. The proposed solution is to include the salt and iterations in the hash (as discussed in the previous forum). This is not implemented in the app. Currently does a simple encryption with the public key to prevent basic rainbow table attacks.


Thanks for the clarification. A little more words:

  1. So, I take that even though the public key provided in the repo will (obviously) not be used for deployment, but it IS the one that should be used for provisional certification purposes.
  2. But what pilot pin ID should it be verified against, even after decryption using the corresponding private key? I mean what is the original Pilot pin that the app is encrypting?

  1. Yes.

Bad pilot pin test case issue

Many thanks, man.



I have a query regarding how the app will test the geofence check. Currently, the app generates a PA for the geofence check and the verified PA check without actually knowing the drone location. For the verified PA case,

You have used fixed coordinates for the geofence. In the future, will you be providing an input box for adding custom coordinates?


Yes, To get to know the Drone’s location by the app will vary with every manufacturer. That will hence not be implemented. The app generates a permissio artefact with a fixed hardcoded geofence.

Q : How is this geofence Decided?
A : When the provisional testing process is initiated, the coords will be changed in the source code to the loccation where the testing will be conducted.

All manufacturers are advised to change the location themselves in the app to test their system against the app in the location of their choice.

Hope that answers your questions.

P.S- @all, Thanks for all the feedback and questions :smile: . please do ask more questions and offfer feedback, that will help other people catch up quickly to the development.


Is anyone aware of any tool available which would facilitate in this process? Or will have to do with Gmaps?
The test would become a little cumbersome, and it can’t really be said if these kind of changes in the source code of a ‘test tool’ during the tests would make a good impression on the Testing authorities. Don’t want them to later discard the whole thing.

Also, as the Permission Artefact is updated with certain other details like adcNumber, ficNumber, maxAltitude, should we be looking to add them as well, in the generated Permission Artefacts?


@sachman I agree, if we are working on an application we need to build something that can test each and every use cases as mentioned by DGCA in the documents

  1. The current application is not using chain of certificates for signing of Permission Artefact as it is done by DigitalSky Portal, I have highlighted this issue previously. Same is the situation with LogFile.
  2. Also the Flight log upload part, it’s not checking the logging parameters and format. I hope that will be done in the near future.

We have already implemented this type of signing and verification long back ago that doesn’t mean our work is done. We should concentrate on developing end to end integration(i.e. sync with server side code)

Yes as mentioned by @sidbh previously, the public key or certificate received during the registration of drone will be used for verification. Also, the verification of PA on RFM side needs more attention as mentioned by @sidbh in the following post:
Permission Artefact Verification on RFM using X509Certificate OpenSSL


The coordinates can be easily extracted by any GIS or map tool. Shouldn’t be an issue at all.

The testing location is not fixed yet. There is no correspondence on where the testing will be performed. But if anyone wants to test the app, they need to have some coorinates. That’s why the source code is released.

Of course, when deployed to the testing authorities, a final build of the app will be used with the right coordinates. They will be using a build of the app and will not change any of the internal source code.

Indeed, Chandan. Please do list features we can collaboratively add that are agnostic to manufacturer implementations, so we can make the tool more robust.

Like you rightly mentioned, we need clarity on the the details of the PA verification in the RFM.

yes, Can you help with a PR on this ?



It seems the current NPNT tool has some issues with the uploadLog functionality. Log structure for json file is not yet clear so we are unable to verify the signature for generated log.

We have created sample log file (with hardcoded values of variables as of now) in json format. I couldn’t attach the file over here so just took snapshot of it and attaching herewith.

We have also developed GUI where there is one verify button after clinking on which it asks for logfile and public key against which file has to be verified. This application is developed using C++ and it is working well.

We would like to hear the feedback about json file creation and its verification.

@nihal @cks123 If it is required to be integrated in python script, i will share the c++ code for both creation of json log file and it’s verification


Yes, Nikhil.

The Schema is specified in the RPAS guidance Manual. But as we can see in various implementations by different manufacturers, there are some minor details to be ironed out. See here -Logs Generation, Signing & Bundling

If you do wish to share the source code. It would be helpful to everyone.