Trust Boundary Diagram
Visual mapping of trust boundaries across 6 architectural layers. Each boundary represents a point where authentication, authorization, or data validation occurs. Understanding these boundaries is essential for security evaluation.
System Trust Boundary Diagram
The diagram below shows how data flows through JIL's architecture, crossing trust boundaries at each layer. Orange dashed lines indicate trust boundary crossings where authentication or validation is enforced.
Trust Boundary Details
Each trust boundary enforces specific authentication and validation rules. Crossing a boundary without proper credentials results in request rejection.
Boundary 1: TLS + Authentication
All external traffic must use HTTPS (enforced by Cloudflare). API requests require JWT bearer tokens. WebAuthn provides passwordless authentication for wallet operations.
Boundary 2: JWT Validation
Caddy forwards authenticated requests to backend services. Each API service validates JWT claims including user identity, permissions, and token expiry. CORS enforcement restricts origins.
Boundary 3: MPC Authorization
Settlement requests require MPC signing ceremony. The user's key shard must participate. Policy engine evaluates corridor rules before forwarding to the signing quorum.
Boundary 4: Independent Signing
Settlement proposals are broadcast to the independent signing-node network. The signing quorum must attest before finalization. Each signing node independently evaluates the proposal against its policy engine.
Boundary 5: Cryptographic Verification
All data writes to the ledger are cryptographically signed. Hash chains provide tamper detection. Data reads verify integrity before serving.
Boundary 6: External Chain
Bridge operations verify deposit events on Ethereum via the chain watcher. Smart contract interactions use verified ABI. Rate limits bound bridge throughput.
Data Flow Classification
| Data Type | Classification | Encryption | Boundary Restrictions |
|---|---|---|---|
| User key shards | Critical | AES-256-GCM at rest, never transmitted | Never leaves Layer 4 (MPC cosigner) |
| Signing-node keys | Critical | AES-256-GCM at rest, HSM storage | Never leaves Layer 5 (signing node) |
| Customer result payloads (CREB™, T1/T2/T3, AVA™ outputs) | Confidential | TLS in transit; customer-owned AWS S3 at rest (customer's KMS, customer's region) | Never persisted in JIL infrastructure - see Data Architecture |
| Settlement attestations (anchor record) | Confidential | Evidence ledger holds hashes + signatures only; payload-free | Independent signing nodes across 13+ jurisdictions; no single point of compulsion |
| Identity verification | Confidential | TLS in transit; processed in JIL service memory only; results stream to customer S3 | Processed at Layer 3 (BID), not stored in ledger |
| Public chain data (external bridge sources) | Public | TLS in transit | Read-only from Layer 6, served via Layer 3 |
| Monitoring telemetry | Internal | Internal network only | Collected at Layer 5, processed by the fleet control plane |
Authentication Methods by Layer
| Layer | Authentication | Authorization |
|---|---|---|
| External to Edge | TLS client hello, Cloudflare WAF | Rate limiting, IP reputation |
| Edge to Application | JWT bearer token, WebAuthn | Role-based (user, admin, service) |
| Application to Settlement | MPC signing ceremony | Policy corridor matching |
| Settlement to Signing Nodes | Ed25519 proposal signature | Independent signing quorum threshold |
| Signing Nodes to Data | Service credentials, connection pooling | Schema-level access control |
| Control plane to Signing Nodes | API key (x-api-key header) | HMAC-authenticated commands |
External Integration Points
The following external systems interact with JIL across trust boundaries. Each integration point has specific security controls.
- Ethereum mainnet: Bridge deposits/withdrawals via JILBridge.sol. Chain watcher reads events from verified contract address only.
- Cloudflare: TLS termination, DNS resolution, DDoS protection. Within trust boundary for edge operations.
- Hetzner infrastructure: Server hosting. Not trusted for data integrity - all data is cryptographically verified.
- Identity verification vendors: BID service integrates with 7 external vendors for KYC checks. Vendor responses are verified and cached.
- Hetzner S3: Object storage for documents and backups. Encrypted at rest, access key authenticated.
Ready to verify?
Start with a structured POC. Evaluate JIL settlement infrastructure on a single corridor.