Inventory Service

Andi Lamprecht ·2026-05-11· 9 min read· Accepted

Inventory service

Glossary

CRL - Certificate Revocation List. It is a list of digital certificates that have been revoked by the
issuing Certificate Authority (CA) before their scheduled expiration date.

OCSP - Online Certificate Status Protocol. It’s a protocol used to check the revocation status
of an X.509 digital certificate. It’s an alternative to using Certificate Revocation Lists (CRLs).

Certificate Serial Number - is a unique identifier assigned by the Certificate Authority (CA)
to each certificate at the time of its creation. It is a critical component of a certificate
and plays a key role in managing the lifecycle of certificates.The serial number is included
in the certificate itself and can be viewed by inspecting the certificate. Serial number
is used for revocation, uniqueness and auditing.

Context

An Inventory service is to be established to track all Unmanned Aerial Vehicles (UAVs)
and manage the generation and revocation of their mutual Transport Layer Security (mTLS)
certificates. Each UAV is associated with an environment through either manual or factory
provisioning, which involves providing them with the host address of the Inventory and an
mTLS client certificate. This certificate enables the UAVs to verify their identities to the Inventory.

Initially, all factory-provisioned UAVs may possess the same client certificate. However, upon their first
interaction with the Inventory, individualized certificates should be generated and issued.
This process personalizes the UAV’s authentication, bolstering the security of the system.
Our system is designed to do more than just validating the authentication of UAVs.
It also ensures that each UAV is connected exclusively to its corresponding Avatar service.
This safeguard provides an additional layer of precision and security, maintaining a one-to-one or
many-to-one relationship between each UAV and Avatar service. This unique pairing optimizes the
utilization and management of resources while maintaining a secure and efficient operational framework.

Considered options

Option 1

The Inventory service is equipped with an API that facilitates the generation and revocation of
mTLS (mutual Transport Layer Security) certificates. Moreover, it has a mTLS proxy at its front of avatars.
mTLS proxy is responsible for terminating mTLS in k8s cluster and validating Certificate Revocation Lists (CRL).
This structure ensures secure and efficient certificate management while maintaining
the integrity of cloud-based communications.

First check in

New Unmanned Aerial Vehicles (UAVs) equipped with factory-provisioned mTLS client certificate initially
connect to the Inventory service, submitting unique information for validation by the manager.
Upon receiving this data, the Inventory service generates and dispatches a unique request ID,
which the UAV is to use for all subsequent communications until the approval process is completed.

The data provided by the UAV for validation purposes should be unique and easily verifiable,
such as the UAV’s serial number, MAC address, and similar identifiers. This information facilitates
a smooth and efficient validation process for the Inventory manager.

While the factory-provisioned mTLS certificates do provide a robust layer of security,
a scenario where these credentials get compromised could leave our system vulnerable to
unauthorized UAV simulations. An attacker with access to these certificates could feasibly
imitate legitimate UAVs, possibly gaining unauthorized access to our system and sensitive data.

To mitigate this risk, a human-in-the-loop validation process has been implemented.
Once the Inventory manager receives the validation request from a UAV, they are tasked with reviewing and
either approving or denying it. This human intervention introduces an additional layer of security
by providing subjective judgement and decision-making that an automated system might miss.

Once the Inventory manager receives the UAV’s request, they are responsible for
reviewing and deciding to approve or deny it. If the request is approved, the Inventory
service generates a personalized mTLS client certificate, which is then transmitted back
to the UAV and securely stored within the database.
This process ensures secure UAV communication and robust data integrity.

Importantly, these certificates are set with an expiration date.
The expiration serves as a built-in safety measure, ensuring that certificates are regularly updated
and that any compromised certificates can’t be used indefinitely.
Regular monitoring and notification systems should also be in place to notify when certificates
are nearing their expiration, thus allowing timely renewal and preventing service disruption.

We could implement a pre-expiration alert system that triggers certificate renewal procedures well before actual expiry.
This ensures the UAV has a valid certificate for its entire flight duration.
Additionally, we could set a default expiry time as midnight, night is our non-operational hours.

This process is essential in establishing a secure identification protocol for new UAVs.
The paramount concern here is the scenario where factory-provisioned mTLS credentials are compromised,
leaving our system vulnerable to unauthorized UAV simulations. As a preventative measure,
all new UAVs must go through a validation and approval process managed by an authorized supervisor.
This extra layer of security ensures that only validated UAVs can access and interact with our system,
significantly reducing the risk of potential breaches.

DB

To support certificate revocation, our system will maintain a database that
includes each certificate’s serial number and authority identifier. These details are
sufficient for constructing a Certificate Revocation List (CRL) or for supporting an Online
Certificate Status Protocol (OCSP) server, both of which are crucial for maintaining the
integrity of the system’s cryptographic security.

An example of a similar implementation can be found in the Cloudflare’s CFSSL project,
available at https://github.com/cloudflare/cfssl/tree/master/certdb. In this example,
not only are the certificate details stored, but additional metadata associated with
each certificate is also maintained. We can leverage a similar approach to attach the
UAV’s ID or any other relevant information to the request,
allowing for efficient certificate tracking and UAV identification.

Connect to avatar

Upon successful check-in with the Inventory server, the Unmanned Aerial Vehicle (UAV)
receives three key files: ca.pem, client.pem, and client-key.pem.
These files contain vital information required for mutual Transport Layer Security (mTLS) authentication.
With these files in place, the UAV is now capable of securely connecting to its designated Avatar service via the mTLS proxy.

Inventory responsibilities

Comprehensive UAV Catalog: Provides a complete list of all registered UAVs,
facilitating efficient tracking and administration of the UAV fleet.

Certificate Revocation: Allows for the immediate revocation of UAV certificates.
This feature is crucial for maintaining security, especially in instances where a
UAV may have been compromised or needs to be decommissioned.

New UAV Integration: Accepts connections from newly produced UAVs that are equipped
with factory-provisioned certificates. The service then generates and issues a unique
mTLS client certificate for each UAV, enhancing their security by providing them with a personalized authentication method.

UAV Approval Management: Handles the validation and approval process for new UAVs.
The system accepts requests, assigns unique IDs for tracking, and approves or denies requests based on the provided unique UAV data.

Certificate Generation and Dispatch: Upon approval of a UAV request,
the system generates an mTLS client certificate, sends it back to the UAV,
and securely stores a record in the database.

Certificate and Authority Identifier Database: Maintains a database of
certificate serial numbers and authority identifiers, critical for creating a
Certificate Revocation List (CRL) or supporting an Online Certificate Status Protocol (OCSP) server.

Example implementation of mTLS proxy in PoC folder.

Option 2 TBD

Inventory service and mtls on cloudflare. Can’t be tested only with cloudflare enterprise subscription

Option 3

Option number 1 with cloudflare spectrum.

Cloudflare Spectrum is a service offered by Cloudflare that extends its protection
to non-web protocols, including email, SSH, and custom protocols. It’s designed to protect services
that are exposed to the internet but aren’t HTTP/HTTPS based.

Option 4

Option 1 but without mTLS proxy and CRL.

The Inventory service is equipped with an API specifically designed for the generation
of mTLS (mutual Transport Layer Security) certificates, as well as for managing
mTLS termination within the Avatar service. It provides a unique set of Certificate Authority (CA),
server, and client certificates for each UAV, enhancing the security of each individual unit.

Under this architecture, there’s no requirement for a Certificate Revocation List (CRL) or
an Online Certificate Status Protocol (OCSP) server. This is because each UAV utilizes a distinct CA certificate.
Additionally, each Avatar instance is initiated with a unique CA and server certificate pair,
ensuring that only the corresponding UAV can establish a connection.

Before initiating a new Avatar, the Avatar Controller should communicate with the Inventory Service
to obtain the necessary set of files: ca.crt, server.crt, and server.pem. Each Avatar will possess
a unique set of these files, ensuring secure and exclusive communication channels.

While this step is not mandatory for option 1, in scenarios where option 1 is chosen, the system
would need to handle a Certificate Revocation List (CRL) or
Online Certificate Status Protocol (OCSP) as part of the security measures.

The Inventory service maintains a record of all certificates, making revocation straightforward.
If a certificate needs to be revoked, the associated CA.crt can simply be removed from the database
and the corresponding avatar shut down. Subsequently, the UAV will lose its ability to connect to both
the Inventory and Avatar services. In order to re-establish connections, the UAV would have to undergo the registration process anew.
This mechanism ensures immediate disconnection of compromised or invalidated UAVs,
while offering a path for reintegration post re-registration.

DB

Compared to the first option, this approach necessitates storing both private and public CA keys for each UAV in the database.
The server certificates could either be generated dynamically upon a request from the avatar controller,
or be pre-generated and stored within the database as well.

Decision

Option 1:
This approach involves managing a Certificate Revocation List (CRL) or
Online Certificate Status Protocol (OCSP) server. It adds a layer of complexity, as you would need to
actively maintain and update the revocation list or OCSP responses.
However this option looks more flexible and we can support many-to-one relations
between UAVs and avatar and it might be very useful with a large fleet of UAVs.

Option 4:
This approach requires the Avatar Controller to communicate with the Inventory Service
to obtain unique certificate files for each spawn of Avatar. It simplifies the process
and enhances security by ensuring each Avatar-UAV pair has a unique set of certificates.
But makes for complex implementation of inventory and avatar controller.
And this method avoids the need for managing a CRL or OCSP server,
which can be advantageous in terms of resource allocation and system complexity.

After reviewing we have decided to proceed with Option 4 for our UAV certification process.
We believe that Option 4 best balances our need for individualized security per UAV,
while maintaining manageable overhead for certificate management.
It provides a robust framework to ensure the secure identification and operation of our UAVs.

Consequences