4. Security Model
4.1 Trust & Threats
Trust Assumptions:
Intel/AMD TEE hardware is trustworthy
TLS certificates are valid
Client devices can verify attestation
Platform operator (Secret Network) is non-malicious
Threat Actors:
External Attacker: Attempts to compromise service from internet
Malicious Operator: Service operator attempts to extract keys
Physical Access: Attacker with physical access to hardware
Quantum Computer: Future adversary with CRQC
Insider Threat: Compromised employee or contractor
4.2 Security Guarantees
Attack Vector Mitigations:
Memory inspection
Intel TDX memory encryption
TEE attestation
Code tampering
Measured boot, reproducible builds
Attestation report
Key exfiltration
TEE isolation, no debug interfaces
Remote attestation
Replay attacks
Timestamp validation, nonces
JWT exp claim
Rate limit bypass
Sliding window per-user limits
Enforced in TEE
Quantum attacks
Post-quantum algorithms
NIST-standardized
Operator access
Session mode (no persistence)
Auditable
Side-channels
Constant-time crypto, blinding
Reference impl.
4.3 Attestation
Remote Attestation Workflow:
Attestation Report Contains:
MRENCLAVE: Hash of code + data loaded in TEE
MRSIGNER: Public key of code signer
ISV_PROD_ID: Product identifier
ISV_SVN: Security version number
Report Data: Custom data (e.g., service public key)
Reproducible Builds: Clients can rebuild Docker image and verify hash matches attestation.
4.4 Compliance
Current:
✅ NIST PQC standards (FIPS 203, 204)
✅ TEE-based isolation (comparable to FIPS 140-2 Level 2)
✅ Audit logging
✅ SOC 2 Type II path (Secret Network platform)
Phase 2 (CloudHSM):
✅ FIPS 140-2 Level 3 certification
✅ PCI-DSS compliance
✅ HIPAA technical safeguards
✅ FedRAMP eligible
Last updated