No Permission No Take-off

NPNT

NPNT or No Permission No Take-off specifications published first in DGCA RPAS Guidance Manual provides technical guidance to RPAS Manufacturers and Service Providers. It lays out the work plan and rules to comply with the specification and fly drones in India. It helps in tracking the drone’s whereabouts and functions on an entity called RFM or Registered Flight Module, which has unique identifiers for an individual drone. Though NPNT is still evolving, it has laid out a sturdy foundation for the future.

RFM has three main functionalities, namely Drone Registration, Permission to fly and Flight log data verification. RFM has been provided with two levels of NPNT Compliances:

Level 0: The key creation, cycling, and storing unique parameters are done through software run on the drone’s companion computer. The keys and any other data stored in this software shouldn’t be accessible to the other parts of the host system. There are quite a few issues with this compliance; some are that the security measures could be bypassed easily. Since this software and other significant apps use shared memory, it may cause performance issues. DGCA has now started referring to this compliance as provisional.

Level 1: This compliance needs specific FPGA hardware that supports chip-level security mechanisms to perform sensitive procedures, ensuring that the data and keys are more secure and cannot be tampered with, maintaining the integrity and authenticity of the files.

All the main computing for key generation, storage, cycling and storing flight log data should take place in a TEE Architecture or Trusted Execution Environment, which should be quarantined from any access other than the DigiSky servers.

The main function of NPNT is to build a unique identity for the drone, authenticate mission plans and validate log data. My main focus in this blog is to authenticate Mission plans.

As an operator, you would be having a pilot ID, a UIN for the organisation and a UIN for the drone. Now create a Flight Plan on your GCS, mention the time of take-off, landing time (note that if the drone lands after this, you would need to log your grievance with the DigiSky portal), take off latitude and longitude points, pilot ID and drone ID, and send this data to Digisky so that they can validate it. When I say validate, they just import these details into their server and create a permission artefact signed by a DigiSky Public Key. Once you receive this key, you again need to validate it with your RFM’s public key to allow your drone to arm. This process should be done under 3 minutes from when the Permission Artefact has been generated, or the session would be invalidated.

This process would be the same in either Level 1 or Level 0 compliance, but a level 1 is touted to be more secure and reliable.

Once the flight mission is finished, you would again need to send your flight log, signed by your RFM public key, to the DigiSky servers to validate your flight. This is a standard rule to find any discrepancies with the initial provided and real flight plan and be debarred if a synthetic flight log is given. This synthetic flight log could easily be differentiated from the original flight flog by sope parameters available in the Permission Artefact, not accessible to the general public.

All the above process should be initiated automatically as a mission is planned to help get any discrepancies with any other flight plan. The best method is to implement a NPNT check in the GCS as soon as you create a mission.

References:

DGCA RPAS manual — https://bit.ly/3ALlG9t

Gazette: https://bit.ly/2XL3YUN
BIS Standards: https://bit.ly/3CLPMdm