Security Architecture
Obscura is built on a foundation of “security by design.” Our architecture combines hardware-grade isolation, cryptographic verification, and decentralized consensus to create a system where users retain full control over their sensitive data while enjoying verifiable trust.
This page details the technical security measures protecting your API keys, trading data, and privacy.
1. Trusted Execution Environments (TEEs)
1.1 AWS Nitro Enclaves
Obscura leverages AWS Nitro Enclaves—hardware-isolated compute environments—to create what we call The Citadel: a fortified zone where all sensitive operations occur.
What Nitro Enclaves Provide:
| Feature | Implementation |
|---|---|
| Hardware Isolation | No persistent storage, no interactive access, no external networking |
| Memory Encryption | All memory is encrypted by the Nitro Hypervisor |
| Attestation | Cryptographic proof of code integrity before secret access |
| Minimal Attack Surface | No SSH, no shell access, no administrative interfaces |
1.2 How We Use TEEs
API Key Management Flow:
- Encrypted Storage: User API keys are encrypted with a master key before ever reaching our systems
- Secure Transmission: Keys travel to the enclave over an encrypted vsock channel
- Attested Decryption: The enclave proves its identity to AWS KMS before receiving decryption keys
- In-Memory Signing: Trade orders are signed entirely within protected memory
- Immediate Purging: Plaintext keys are wiped from memory microseconds after use
The Critical Guarantee: No human—not even Obscura employees or AWS administrators—can ever access your plaintext API keys.
1.3 Cryptographic Attestation
The attestation process ensures that only the exact, audited version of our code can access secrets:
1. Enclave boots → Requests attestation document from Nitro Hypervisor
2. Document contains PCR hashes (code fingerprints)
3. Enclave sends document to AWS KMS
4. KMS verifies signature AND compares PCRs to allowlist
5. If match → KMS releases decryption key
6. If mismatch → Access deniedAny code modification—even a single changed byte—alters the PCR hash, breaking attestation and locking the enclave out of all secrets.
2. Zero-Knowledge Proofs
2.1 Privacy-Preserving Verification
Obscura uses Zero-Knowledge proofs to verify trading performance without exposing:
- Individual trade prices
- Position sizes
- Entry/exit timing
- Trading strategies
- Exchange used
What We Prove:
| Metric | Proven Without Revealing |
|---|---|
| Profitability | Individual trade P&L |
| Win Rate | Which trades won/lost |
| Sharpe Ratio | Volatility calculations |
| Max Drawdown | Specific loss events |
| Consistency | Trading frequency |
2.2 Technical Implementation
| Component | Technology |
|---|---|
| Language | Noir (Rust-like syntax for ZK circuits) |
| Proving System | UltraHonk (no trusted setup required) |
| Recursive Proofs | Aggregate thousands of trades into single verifiable proof |
| On-Chain Verification | Constant gas cost regardless of trade count |
2.3 Nillion Integration
Obscura integrates with Nillion to enhance our privacy infrastructure:
| Nillion Component | Obscura Use Case |
|---|---|
| NilDB | Secure storage of encrypted trader metadata |
| Nil Compute | Blind computation on sensitive trading signals |
| SecretLinking | Privacy-preserving trader-copier matching |
How Nillion Augments Our Architecture:
- Beyond TEEs: Nillion's multi-party computation (MPC) adds a layer of cryptographic security that complements hardware isolation
- Decentralized Secret Management: API key shards distributed across Nillion's network—no single point of compromise
- Private Set Intersection: Match traders and copiers based on preferences without revealing those preferences
The Nillion integration creates a defense-in-depth strategy: even if an attacker somehow breached the TEE, they would still face Nillion's distributed secret sharing.
3. Decentralized Oracle Network (Sentinel DON)
3.1 Byzantine Fault Tolerant Consensus
The Sentinel DON replaces centralized data feeds with a distributed network of independent nodes:
| Aspect | Specification |
|---|---|
| Consensus | BFT (Byzantine Fault Tolerant) |
| Nodes | ≥16 independent operators |
| Tolerance | Up to ⅓ Byzantine nodes |
| Finality | Cryptographic finality within seconds |
3.2 Cryptoeconomic Security
- Staking: All node operators stake ZEN tokens as collateral
- Slashing: Malicious reporting results in stake forfeiture
- Incentives: Honest reporting earns fees; cheating becomes economically irrational
3.3 Universal Exchange Adapters (UEA)
The DON connects to both centralized and decentralized exchanges through standardized adapters, ensuring data integrity regardless of source.
4. End-to-End Encryption
4.1 Data in Transit
| Layer | Protocol |
|---|---|
| Web Interface | TLS 1.3+ |
| API Communication | TLS 1.3+ with certificate pinning |
| Service-to-Service | mTLS with rotating certificates |
| Enclave Communication | Encrypted vsock channel |
4.2 Data at Rest
| Data Type | Encryption | Key Management |
|---|---|---|
| API Keys | AES-256-GCM | AWS KMS + Enclave attestation |
| User Data | AES-256-GCM | Envelope encryption |
| Backups | AES-256 | Offline HSM-stored keys |
| Logs | Redacted (no PII) | N/A |
4.3 Key Management Hierarchy
Master Keys (HSM)
↓
Key Encryption Keys (AWS KMS)
↓
Data Encryption Keys (per-user/per-session)
↓
Encrypted User Data5. Threat Model & Mitigations
STRIDE Analysis
| Threat | Scenario | Mitigation |
|---|---|---|
| Spoofing | Attacker impersonates legitimate service | mTLS, certificate pinning, domain validation |
| Tampering | Oracle manipulation to falsify reputation | BFT consensus + economic slashing |
| Repudiation | Trader denies submitting trades | Cryptographic signatures + on-chain proofs |
| Information Disclosure | API key extraction from memory | TEE isolation + Nillion secret sharing |
| Denial of Service | API flooding | Rate limiting + DDoS protection |
| Elevation of Privilege | Internal employee abuses access | No human access to keys; TEE attestation |
6. Third-Party Audits
| Audit Type | Auditor | Frequency | Status |
|---|---|---|---|
| Smart Contract Security | [Auditor Name] | Pre-deployment + annual | Scheduled Q2 2026 |
| TEE Configuration | [Auditor Name] | Annual | Completed Jan 2026 |
| ZK Circuit Verification | [Auditor Name] | Per circuit update | In progress |
| Penetration Testing | [Auditor Name] | Quarterly | Next: Mar 2026 |
| SOC 2 Type II | [Auditor Name] | Annual | Target: Q4 2026 |
Audit reports available to institutional partners under NDA. Contact investors@obscura.finance.
7. Bug Bounty Program
Obscura maintains an active bug bounty program:
| Severity | Reward Range |
|---|---|
| Critical | $50,000 – $100,000 |
| High | $10,000 – $50,000 |
| Medium | $2,000 – $10,000 |
| Low | $500 – $2,000 |
Scope:
- Smart contracts
- TEE integration
- ZK proof circuits
- API security
- Authentication mechanisms
Reporting: security@obscura.finance (PGP encrypted preferred)
8. Compliance & Certifications
| Standard | Status |
|---|---|
| SOC 2 Type I | In progress (Q3 2026) |
| ISO 27001 | Planned (Q1 2027) |
| GDPR | Compliant |
| CCPA | Compliant |
| PCI DSS | N/A (no card storage) |
9. Frequently Asked Questions
Q: Can Obscura employees see my API keys?
A: Absolutely not. API keys are encrypted and only decrypted inside hardware-isolated TEEs. No human—including AWS administrators—can access the plaintext.
Q: What happens if AWS is compromised?
A: Our TEE architecture assumes the host is untrusted. Even with full AWS compromise, the enclave's hardware isolation prevents unauthorized access. Additionally, Nillion integration distributes trust across multiple cryptographic layers.
Q: How do I know the TEE is running the right code?
A: The attestation process cryptographically proves the exact code version. You can independently verify the PCR hashes against our published values.
Q: What if someone steals my API keys from the exchange side?
A: We strongly recommend configuring API keys with “withdrawals disabled.” Obscura never requests withdrawal permissions. Keys should also be rotated regularly.
Q: How does Nillion integration improve security?
A: Nillion adds a layer of cryptographic secret sharing. Even if an attacker bypassed the TEE, they would only obtain fragments of keys, useless without the complete set distributed across the Nillion network.
Q: Are ZK proofs truly private?
A: Yes. The proofs reveal only what you authorize—typically performance metrics. Individual trade details remain mathematically hidden. However, blockchain anchors are public; pseudonymity depends on your actions.
10. Responsible Disclosure
If you believe you've found a security vulnerability:
- Email: security@obscura.finance
- PGP Encryption: Use our published key
- Details: Include steps to reproduce, potential impact
- Timeline: We acknowledge within 24 hours
- Disclosure: Coordinated disclosure after fix
We commit to:
- No legal retaliation against good-faith researchers
- Public acknowledgment (with consent)
- Bug bounties as specified
11. Security Roadmap
| Quarter | Initiative |
|---|---|
| Q1 2026 | TEE attestation public dashboard |
| Q2 2026 | Formal verification of core ZK circuits |
| Q3 2026 | SOC 2 Type I completion |
| Q4 2026 | MPC integration expansion with Nillion |
| Q1 2027 | ISO 27001 certification |
| Q2 2027 | Public verifiability dashboard |
12. Summary: Defense in Depth
Obscura's security architecture employs overlapping layers:
Layer 1: Hardware Isolation (Nitro Enclaves)
Layer 2: Cryptographic Privacy (ZK Proofs)
Layer 3: Distributed Trust (Nillion MPC)
Layer 4: Decentralized Consensus (Sentinel DON)
Layer 5: Economic Security (Staking + Slashing)
Layer 6: Encryption (TLS + AES-256)
Layer 7: Access Controls (MFA + Least Privilege)No single point of failure. Compromising any one layer leaves the others intact.
Security inquiries: security@obscura.finance
Vulnerability reporting: PGP key available on website
Compliance / Privacy: compliance@obscura.finance