ASR-0005 Identity and mTLS Private Key Security

Andi Lamprecht ·2026-05-11· 10 min read· Proposed

ADR-0274 · Author: Sybil Melton · Date: 2026-03-12 · Products: platform
Originally ASR-0005 Identity and mTLS Private Key Security (v13) · Source on Confluence ↗

Summary

Using NIST standards as a blueprint, these architecture requirements transition the platform to a “never trust, always verify” Zero-Trust “Bring Your Own Drone” (BYOD) model, shifting from long-lived, server-side credentials to Just-In-Time (JIT) ephemeral identities. This approach eliminates “Key Custody” liability—meaning the platform never possesses a drone’s private keys—and ensures that a compromise of a single device or service cannot lead to a fleet-wide breach.

Cryptographic microsegmentation continues to ensure encryption protects data in transit between individual workloads (such as UAV to Avatar). Security keys are not persisted (hardened, memory-only lifecycle) and wiped immediately upon session termination, satisfying NIST 800-207 and FIPS 140-3 standards for “Zeroization.” By using “Distroless” container images that lack shells or system tools, we create a “binary-only” sandbox. This prevents attackers from installing malware or moving laterally through our network, even if they manage to exploit a communication tunnel.

Ultimately, this strategy also aligns with FedRAMP (NIST 800-53) requirements, moving sensitive data out of the “at-rest” storage category and into protected memory. This significantly simplifies our audit profile and provides a competitive advantage by offering customers hardware-level identity protection and verifiable data privacy.

Requirements

Client-Side Requirements (The Drone)

Focus: Identity Sovereignty, Non-Repudiation, and Local Key Custody.

REQ-C1: Local Key Generation (The Passport)

Requirement: The drone must generate its own private/public key pair locally during the enrollment phase. This shifts the “Key Custody” liability from the platform to the hardware owner.

Technical Goal: To ensure the Private Key never leaves the drone’s hardware.
Industry Standard: OWASP IoT (L2) and NIST SP 800-213 mandate that private keys should never be transferred from the device. Local generation ensures the platform is a “witness” to the identity, not the “owner.”

REQ-C2: Secure Local Storage & Hardening

Requirement: The permanent private key must be stored in a protected environment. If a Trusted Platform Module (TPM) is not available, then a “secure software vault”. On Docker-based drones, this requiresdisk encryption, Read-Only Volume mounts, and Non-Root execution.

Technical Goal: To protect the “Passport” from unauthorized access by other processes or physical theft.
Industry Standard: FIPS 140-3 requires protection of Critical Security Parameters (CSPs). For non-TPM devices, NIST 800-53 (SC-28) covers “Protection of Information at Rest” via encryption and access controls.

REQ-C3: Session-Based CSR Submission

Requirement: The platform must support a Certificate Signing Request (CSR) workflow where the drone generates generate a new volatile key pair in RAM and submit a CSR signed by its “Passport.”.

Technical Goal: To request a temporary “Boarding Pass” (Session Certificate) without exposing the permanent identity to the mTLS tunnel. While TLS provides encryption, the CSR provides Authentication. It allows us to issue a unique “Boarding Pass” (Session Cert) that is strictly bound.
Industry Standard: NIST SP 800-57 Part 1 recommends that short-lived session keys be used to prevent “retrospective decryption”. NIST SP 800-207 (Zero Trust Architecture) (Section 2.1) requires that all communication is encrypted and authenticated based on the current state of the session, rather than a long-lived, broad-trust credential.

Server-Side Requirements (The Uncrew Platform)

Focus: Cryptographic Isolation, Attack Surface Reduction, and Zero-Persistence.

REQ-S1: Just-In-Time (JIT) Issuing Authority

Requirement: There is a service that acts as a volatile CA, minting session-specific certificates only after verifying the drone’s signed CSR.

Technical Goal: Cryptographic Micro-segmentation. It ensures that a valid cert for Drone A cannot talk to Avatar B. Additionally, this allows the server to revoke access mid-flight. If a drone is reported stolen, we “cancel the Passport”; the drone can no longer get a “Boarding Pass,” regardless of its TLS capabilities.
Industry Standard: NIST SP 800-207 (Zero Trust Architecture) requires that all communication is authenticated based on the current state of the session, rather than a broad-trust credential.

REQ-S2: Volatile Secret Lifecycle (No Persistence)

Requirement: All session-specific keys must exist only in memory (tmpfs) and never be written to persistent storage (CloudSQL/K8s Disks)

Technical Goal: Eliminates the risk of data leaks from database backups or disk forensics.
Industry Standard: NIST 800-53 (SC-28). By using RAM-backed storage, you technically move these secrets out of the “Information at Rest” category, simplifying federal audit requirements.

REQ-S3: Workload Hardening (Distroless)

Requirement: GKE Pods must use “Distroless” images containing only the binary—no shells, package managers, or system tools.

Industry Standard: CIS Google Kubernetes Engine (GKE) Benchmark explicitly advises minimizing the container attack surface by using minimal base images to satisfy security audits.

REQ-S4: Real-Time Session Termination

Requirement: The Controller must enforce a 1:1 binding between the mTLS tunnel and the Pod lifecycle.
Industry Standard: FIPS 140-3 (Section 4.9.2) requires “Zeroization” of plaintext critical security parameters when a session is closed.

Threat Modeling & Risk Mitigation

The following table identifies threat scenarios in a BYOD (Bring Your Own Drone) environment and how the requirements in this ASR mitigate them.


Threat Actor	Attack Scenario	Impact (Current)	Mitigation
Database Leaker	An internal CloudSQL backup is accidentally exposed or leaked.	Every private key ever generated is now public; the entire fleet must be physically grounded and re-provisioned.	REQ-S2 (No Persistence): There are no private keys in the database to leak. Only public certificates exist, which carry zero risk if exposed.
Physical Thief	A drone is stolen in the field; the thief extracts the private key.	The thief can impersonate the drone, send rogue telemetry.	REQ-C3 (CSR): The key is stored in a hardware-backed enclave or is session-based, making it non-exportable and short-lived.
Insider Threat	A user with DB access tries to “spoof” a drone to steal flight data.	Admin copies the drone’s private key from the DB and mimics the UAV.	REQ-C1, -C2: The admin cannot spoof the drone because Uncrew never possessed the private key. Only the physical UAV holds the key.
Cloud Attacker	An attacker gains “Read” access to the Kubernetes Namespace.	The attacker reads the `Avatar` Custom Resource and steals the private keys.	REQ-S2 (Isolation): Secrets are never in the CR spec; they are injected into memory via `tmpfs`, leaving no footprint for a “Read” observer.
Malicious User	A customer uses an exploit in the gRPC tunnel to “break out” of the tunnel into a remote shell.	Attacker uses `cat` to read `/etc/secrets/key` and `curl` to send it to a remote server.	REQ-S3 (Distroless): The “Distroless” image has no shell or tools; the attacker is trapped in a “binary-only” sandbox with no way to pivot. REQ-S4 (Termination): The crash caused by the buffer overflow triggers the Controller to see the Pod as “Unhealthy.” The Controller immediately kills the Pod and the associated mTLS session, “self-healing” the environment before the attacker can establish a foothold.
Lateral Mover	A compromised Avatar Pod attempts to scan the internal network for the Controller.	Attacker uses `apk` to install `nmap` and begins reconnaissance of the K8s cluster.	REQ-S3 (Hardening): No package manager exists. The attacker cannot install tools or pivot to other pods in the namespace.
Stale Identity	A drone is retired or sold, but its certs are still valid.	A new owner could reconnect to Uncrew using the previous owner’s identity.	REQ-C3 (CSR): Certificate expires after the mission window. REQ-S4 (JIT): Ensures the trusted root for that mission is no longer valid.
Dishonest Operator	An operator performs an unauthorized flight into restricted airspace and then claims their drone was “spoofed” or the data was forged by the platform.	Legal/Regulatory liability for the platform; inability to provide forensic evidence to authorities.	REQ-C1: Because the private key never leaves the drone, only that specific hardware could have signed the session request. The platform holds a “cryptographic receipt” (the signed CSR and mTLS handshake logs) that proves the drone’s unique involvement.
Data Fabricator	A user tries to deny a crash occurred by claiming the telemetry logs were altered by an insider at Uncrew.	Integrity of the flight record is lost; insurance claims become contested.	REQ-S4 (JIT CA): Every session log is tied to a unique, short-lived trust anchor. The 1:1 binding between the mTLS tunnel and the Pod ensures a tamper-evident audit trail that is mathematically linked to that specific flight window.

Shared Responsibility & Exposure Profile

As we move to a BYOD model, the “Security Boundary” must be clearly defined to protect both the platform and the customer. This architecture adopts the “Provider-Consumer” shared responsibility model, similar to AWS or GCP.

Customer Responsibility (The UAV)

The customer or OEM acts as the sole Custodian of the drone’s permanent identity. This places the physical device outside of Uncrew’s “Security Boundary,” significantly reducing platform liability. The Permanent Private Key never leaves the drone’s hardware (REQ-C1). The customer is responsible for the integrity of the physical device and securing the onboard storage (TPM, encrypted disk, or restricted Docker volumes) (REQ-C2). If a drone is stolen, the “Blast Radius” is limited strictly to that single device. Because Uncrew never possessed the private key, no other fleet assets are at risk. Customers must ensure drones maintain connectivity to re-sync and rotate session credentials before they expire.

DroneUp Responsibility (The Uncrew Platform)

Uncrew is responsible for the Attestation of the drone and the strict Isolation of the cloud flight environment. Uncrew verifies the drone’s identity but only signs CSRs to “mint” temporary Session Certificates. We never touch or store the drone’s actual Permanent Private Key (REQ-S1). Uncrew ensures the Avatar Pod is a tool-less, “Distroless” environment. This ensures that even a compromised drone cannot “break out” to access other tenants or core platform infrastructure (REQ-S3). Uncrew guarantees that all session-related cryptographic material exists exclusively in volatile memory (tmpfs). This ensures that when a Pod ends, all sensitive material is “zeroized” (wiped), leaving no forensic footprint on physical disks (REQ-S2/S4).

Compliance & Standards Mapping Table


Proposed Requirement	NIST SP 800-213 (IoT Guidance)	OWASP IoT / ISO 27001
REQ-C1: Local Key Gen	Sec 4.2.1 (Identity): Requires a “Root of Trust” that is difficult to forge. By generating keys on-device, the identity is “hardware-bound.”	OWASP IoT (L2): Mandates that private keys must never be transferred from the device to the cloud.
REQ-C2: Secure Storage	Sec 3.1.1 (Asset Protection): Requires protection of device identifiers from unauthorized modification or disclosure.	ISO 27001 (A.18.1.5): Cryptographic controls must be used to protect the integrity of information on the device.
REQ-C3: Session CSR	Sec 3.3.1 (Data Protection): Requires that sensitive data in transit be protected using verified cryptographic modules and unique session keys.	OWASP IoT (V4): Recommends unique, per-session credentials to prevent large-scale fleet compromise if one key leaks.
REQ-S1: JIT Authority	Sec 4.3.1 (State Monitoring): The system must uniquely identify and authenticate every connection attempt in real-time.	NIST 800-207 (ZTA): Implements Micro-segmentation, ensuring trust is never persistent and must be “earned” per session.
REQ-S3: Distroless	Sec 4.5.1 (Software Integrity): Recommends minimizing unused software/services to reduce the “Attack Surface” of cloud workloads.	CIS GKE Benchmark (5.4.1): Explicitly recommends minimal base images (Distroless) to satisfy security audits and limit lateral movement.

Appendix: FedRAMP & NIST 800-53 Control Mapping

For the future, this table maps the requirements to the specific NIST 800-53 controls required for federal cloud systems.


Proposed Requirement	NIST 800-53 Rev 5 Control	FedRAMP Context & Non-Repudiation
REQ-C1 & C3: CSR Identity	IA-3: Device Identification & Authentication	Satisfies the requirement that the system uniquely identifies and authenticates devices. Non-Repudiation: Proves the device is the sole “owner” of the action.
REQ-S1: JIT Authority	SC-7: Boundary Protection	Protects the cloud boundary by ensuring that a compromise of one “Boarding Pass” (Session Cert) provides zero access to other platform resources.
REQ-S2: No Persistence	SC-28: Protection of Information at Rest	By using tmpfs (RAM), you move the secret out of the “Information at Rest” category, significantly simplifying the encryption-at-rest audit for the database layer.
REQ-S3: Distroless	CM-7: Least Functionality	FedRAMP auditors require that you remove all unnecessary functions. Distroless is the ultimate implemention of “Least Functionality,” as it lacks shells and package managers.
REQ-S4: Real-Time Kill	SI-4: System Monitoring	Linking the tunnel state to the Pod lifecycle provides an automated Incident Response capability, satisfying “Detection and Response” requirements for GovCloud.
Overall mTLS	SC-8: Transmission Confidentiality	mTLS satisfies the requirement that all communications between the “Thing” and the Cloud are encrypted with FIPS-validated or equivalent cryptography.

Cited by queries

Last updated on May 11, 2026

IAM