Where do we begin? A template for complying with NPNT Level-1


#1

Bosch has been working on a reference architecture for NPNT Level-1 compliant drones, leveraging our years of expertise in building secure connected IoT devices. We’ve put together a tiny blog-post which serves as a decent starting point for anyone working on level-1 NPNT compliant RFMs using open standards (wherever applicable).

Although, this is a generic template, it can be expanded to meet the various demands of many UAV applications.

Comments, questions, thoughts are all welcome!


#2

Ardupilot opensource flight controller pretty much customization to fit in this architecture.


#3

Hi Nihal. Thanks for the post. It was very useful and included a lot of information. Could you please clarify on the below mentioned sentence from the post.

To establish mutual trust, DGCA’s public key is to be procured (via a portal account) and securely stored on the drone. This elaborate process allows for a cryptographically secure mutual-authentication scheme between 2 communicating parties.

How and in what stage of the registration process does the manufacturer procure the DGCA’s public key?

Thanks in advance.


#4

Last I checked, the process of procuring a ‘digital-sky’ public key was hacky.

Most implementations rely on extracting the public-key from a certificate embedded in the response of a Fly Drone Permission Artifact Download API call.

You can find the API here - https://digitalsky.dgca.gov.in/api-documentation.

Here’s the rough workflow for the above method -

  1. The digital-sky platform signs a Permission Artifact with its private key.
  2. The public key corresponding to this private key is embedded in an X.509 certificate.
  3. The response to the Fly Drone Permission Artifact Download API call contains both the signature and the certificate.
  4. We extract the public key and use it to verify the Permission Artifact

However, this is not ideal when procuring crypto-keys. For situations such as this, we need to use an out-of-band mechanism to retrieve the public-key for security reasons.

  1. Decoupling the API call from the ‘public key retrieval process’ is recommended as a bug in the API call wouldn’t compromise the entire verification process
  2. Out-of-band mechanisms can further be expanded to add additional authentication schemes such as mutual TLS etc for added security.

Note: I’m not sure if the situation has changed but you can refer to the digital sky forum for more info or the latest RPAS guidance manual - https://go.aws/2T4jdTt

For the what stage part of your question - this has to happen before you can make the Fly Drone Permission Artifact Download API call.


#5

Thank you Nihal. That helped me understand the process.