# 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