mirror of
https://github.com/azaion/loader.git
synced 2026-04-22 06:56:31 +00:00
Oleksandr Bezdieniezhnykh
40 lines
3.1 KiB
Markdown
40 lines
3.1 KiB
Markdown
# 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
|