loader/_docs/02_task_plans/tpm-replaces-binary-split/problem.md

Problem: TPM-Based Security to Replace Binary-Split Resource Scheme

Context

The Azaion Loader uses a binary-split resource scheme (ADR-002) where encrypted resources are split into a small part (uploaded to the authenticated API) and a large part (uploaded to CDN). Decryption requires both parts. This was designed for distributing AI models to end-user laptops where the device is untrusted — the loader shipped 99% of the model in the installer, and the remaining 1% (first 3KB) was downloaded at runtime to prevent extraction.

The distribution model has shifted to SaaS — services now run on web servers or Jetson Orin Nano edge devices. The Jetson Orin Nano includes a TPM (Trusted Platform Module) that can provide hardware-rooted security, potentially making the binary-split mechanism unnecessary overhead.

Current Security Architecture

• Binary-split scheme: Resources encrypted with AES-256-CBC, split into small (≤3KB or 30%) + big parts, stored on separate servers (API + CDN)
• Key derivation: SHA-384 hashes combining email, password, hardware fingerprint, and salt
• Docker unlock: Key fragment downloaded from API, used to decrypt encrypted Docker image archive
• Hardware binding: SHA-384 hash of hardware fingerprint ties decryption to specific hardware
• Cython compilation: Core modules compiled to .so for IP protection

Questions to Investigate

1. TPM capabilities on Jetson Orin Nano: What TPM version is available? What crypto operations does it support (key sealing, attestation, secure storage)? How does NVIDIA's security stack integrate with standard TPM APIs?

2. TPM-based key management: Can TPM replace the current key derivation scheme (SHA-384 of email+password+hw_hash+salt)? Can keys be sealed to TPM PCR values so they're only accessible on the intended device?

3. Eliminating binary-split: If TPM provides hardware-rooted trust (device can prove it's authentic), is the split-storage security model still necessary? Could the loader become a standard authenticated resource downloader with TPM-backed decryption?

4. Docker image protection: Can TPM-based disk encryption or sealed storage replace the current encrypted-archive-plus-key-fragment approach for Docker images?

5. Migration path: How would the transition work for existing deployments? Can both models (binary-split for legacy, TPM for new) coexist?

6. Threat model comparison: What threats does binary-split protect against that TPM doesn't (and vice versa)? Are there attack vectors specific to Jetson Orin Nano that need consideration?

7. Implementation complexity: What libraries/tools are available for TPM on ARM64/Jetson? (tpm2-tools, python-tpm2-pytss, etc.) What's the integration effort?

Constraints

• Must support ARM64 (Jetson Orin Nano specifically)
• Must work within Docker containers (loader runs as a container with Docker socket mount)
• Cannot break existing API contracts (F1-F6 flows)
• Cython compilation requirement remains for IP protection
• Need to consider both SaaS web server and Jetson edge device deployments