Complying with India’s drone policy — a technical deep dive

The market for commercial and law-enforcement related drone usage in India is set to explode in the next few years.

Applications include

1. Precision farming or agriculture.
2. Industrial inspections.
3. 3D terrain mapping and image processing
4. Border defense
5. Hyper-local delivery (including medical supplies)

In short, it’s a huge green-field opportunity but there’s a BIG catch.

There are numerous concerns about a ‘precarious’ future where our skies could be flooded with little flying robots without the oversight of a ‘digitally enforceable’ regulatory framework (key-word being ‘digital’ here).

NPNT or No-permission No-take-off (which forms the foundation of India’s RPAS or drone policy) attempts to resolve this very conundrum and possibly put India ahead of every other country in the UAV space. In some ways, it’s as ambitious as ‘Aadhaar’ in that we could be the first to have a fully functional nation-wide digital platform to identify, register, permit and monitor all UAV traffic (…provided we get it right).

NPNT provides the basis for digital enforceability of India’s drone policy. It specifies a set of technology-related compliance constraints for registration, permission and verification.

1. Drone registration: The drone manufacturer is required to uniquely identify his/her drone and register it with the DGCA.
2. Permission to take-off: The drone operator is required to obtain permission or rights for airspace prior to any flight. For example, you can choose a polygon area of airspace at a particular altitude and for a particular date and time.
3. Verification: Lastly, the drone must generate authentic flight telemetry which can be verified.

Put all of these together and you get — end to end traceability, accountability, a pan-India traffic management solution.

NPNT : lets dive deeper

The NPNT specification published as part of the DGCA RPAS guidance manual is a document that provides technical guidance to drone manufacturers and operators who’d like to sell/operate drones within India’s airspace. It lays out the do’s and don’ts of how to design, build and operate ‘registered flight modules’ or RFMs for short.

Important to note — NPNT is still an evolving standard. Nonetheless, it lays out a solid foundation for the future.

An RFM is basically a software module (or it can a combination of both code and HW) designed to perform 3 core functions - drone registration, permission-to-fly acquisition and flight log-data verification.

It goes without saying, this requires careful consideration and a good deal of deliberation. DGCA currently has 2 levels of NPNT compliance.

• Level 0 —Do everything in software from key generation to signature verification. There are quite a few drawbacks to implementing everything in software (namely not as secure along with performance, battery and compute limitations). In fact, DGCA refers to level 0 compliance as ‘provisional’ at this point.
• Level 1 — For level-1, the spec requires the use of hardware-based (or chip-level) security mechanisms to perform sensitive crypto operations, ensuring a higher level of data confidentiality, authenticity and integrity.

So, lets skip level 0 and go straight to level 1 to figure out what it takes to build a Level-1 NPNT compliant drone. At a bare minimum, we need 3 things to be Level-1 compliant.

1. An Un-forgeable Identity: A unique, trustworthy and verifiable identity for drone authentication.
2. A Secure RFM: Ensure all code involved in the registration, de-registration and permission artefact requisition process (i.e. key generation, digital certificate provisioning, public-key storage, verifying PA digital signatures) is trustworthy.
3. Flight-log data authenticity: Generation of authentic or cryptographically signed flight logs.

Apart from requiring the high levels of security, NPNT makes the use of open standards (wherever possible) an explicit requirement.

We at Bosch have been working on a reference architecture for Level-1 compliant drones, leveraging our years of expertise in securing connected IoT devices. What follows is a templatized starting point for building level-1 compliant RFMs using open standards (wherever applicable).

Note- This is a generic template that can be expanded to meet the various demands of UAV applications.

One of many Possible Solutions:

To achieve all 3, we need a security architecture that combines a hardware root of trust and a trusted execution environment.

Hardware Root of Trust: to serve as our un-forgeable identity store.

A tamper-resistant piece of hardware that provides (at the very least) 3 basic functions

• A unique identity— provides​ a serial number guaranteed to be unique/device.
• Verifiable compute — offload crypto operations i.e. like generating, signing and managing keys that never leave the device.
• Trustable storage — serve as a high security safe for cryptographic key-storage.

Tamper-resistant crypto hardware

Trusted Execution Environment: for RFM security and log authenticity.

1. Secure Boot: The assurance of only genuine code being executed at system start-up.
2. Arm TrustZone-M: The assurance of security critical-code being partitioned of from the rest of the system.
3. Secure Update: The assurance of only genuine upgrade code being accepted and programmed into a device’s MCU/MPU.

Together these 3 security mechanisms offer a trusted execution environment which can be used to host all security critical-code such as key-generation, digital certificate provisioning, public-key storage, verifying PA digital signatures and digital signing of flight logs.

In other words, the RFM module/service which is responsible for all security-critical operations is to be fully hosted within the ‘Trusted Execution Environment’.

A security architecture built on these foundations meets NPNT Level-1 compliance requirements.

Here what it looks like — workflows for drone registration, permission acquisition and data verification pictured here are simplified representations.

An ultra simplified representation of the UAV registration workflow

Note - the above workflow deliberately excludes actual component names — such as GCS, rfm, mgmt client/server etc. for the sake of simplicity.

Manufacturer:

1. The drone generates a pair of (asymmetric public-private) crypto keys via its hardware secure element. The private key remains a secret, never leaves the HSE (i.e. can never be retrieved) but can be used for crypto operations.
2. The associated public key along with a unique ID is used to provision a digitally signed certificate. (which serves as a form of a credential for the drone.)
3. This digital certificate is uploaded to DGCA via one of its digital service providers and is used to uniquely identify the drone (and by extension its manufacturer).

At this point, DGCA has a mechanism to identify and authenticate messages from a registered drone but the same can’t be said for the drone.

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.

A simplified representation of the PA requisition workflow

Operator:

1. An operator (i.e. the remote pilot) has to go through a similar user registration process to identify him/herself to DGCA. Upon signing-up, he/she gets an UAOP — Unmanned aircraft operation permit.
2. After which he/she can apply for a permission artefact.
3. A permission artefact is an electronic representation of a permit to fly granted via one of DGCA’s digital sky service providers. The artefact is digitally signed by DGCA (with its own private key) and delivered to the drone for verification.

Before a drone can fly, it has to ensure 2 things — a permission artefact exists and the permit is valid. Only then is it allowed to ‘arm’ itself and take-off. If any of these 2 conditions are not met, the operator should not be able to fly the drone.

A simplified representation for generating and submitting authentic flight log-data with JSON web tokens.

Drone:

1. The drone must log the following parameters — take-off and landing time and GPS co-ordinates along with instances of Geo-fence breaches.
2. Logs thus generated are to be signed (by the drone’s private key) and uploaded to DGCA via one of the digital sky service providers to screen for permit violations.

Sales pitch part of the blog post:

Bosch security engineering has a considerable amount of experience in designing, evaluating and integrating state of the art ‘security’ into an embedded design.

More specifically for NPNT Level-1 compliance, we can help with

1. Adding crypto-authentication devices (i.e. hardware secure elements) to embedded designs, porting crypto-authentication libraries to various cortex ARM-M processors (with or without an OS)
2. Personalizing elements with rather complex memory layouts (ex: you want to have multiple back-up keys or i2c-bus protection.)
3. Support for surrounding hardware and firmware security with ARM-TrustZone v8-M. (Ex: peripheral access from secure world only and memory layout optimizations to maximize code-space.)
4. Additionally, version 1.0 of the policy also refers to other security specific guidance such as hardware tamper resistance, link-hijack avoidance. We provide extensive pen-tests of embedded hardware —including side-channel attack assessments or RF-interface security assessments via RF reverse engineering.
5. Add secure messaging or logging formats. Ex: port JWT libraries (JSON web tokens — an open standard) to multiple architectures/platforms.

If you’d like to learn more or have some questions, please feel free to drop a note or contact me

Twitter: @npashi

References:

DGCA RPAS manual — https://public-prd-dgca.s3.ap-south-1.amazonaws.com/InventoryList/headerblock/drones/DGCA%20RPAS%20Guidance%20Manual.pdf

ARM TrustZone for Cortex-M — https://www.arm.com/why-arm/technologies/trustzone-for-cortex-m

DGCA — Directorate General of Civil Aviation is the Indian governmental regulatory body for civil aviation under the Ministry of Civil Aviation. https://www.dgca.gov.in/

JSON Web Token (JWT) — an open secure messaging standard (RFC 7519). https://jwt.io/introduction/