xArmor: Split-Channel HTTPS Proxy
A transparent reverse proxy that XorIDA-splits HTTP request bodies across N independent HTTPS connections. No single upstream server sees the full payload. DID mutual authentication between all instances.
The Problem
HTTPS protects data in transit, but the destination server sees everything in plaintext. A compromised server endpoint, rogue admin, or insider threat exposes all request data -- credentials, payment info, medical records.
Modern APIs handle billions of sensitive requests daily. Each request terminates TLS at the server, exposing the full payload to the application layer. Server-side breaches, supply chain attacks, and insider threats mean that transit encryption alone is insufficient.
API keys stored in configuration files create a single authentication point. If the config is compromised, the attacker has full API access. There is no threshold authentication, no split-channel protection, and no way to limit what any single server instance can see.
The Old Way
The PRIVATE.ME Solution
xArmor sits as a transparent reverse proxy that intercepts HTTP request bodies, splits them via XorIDA into N shares, and sends each share over an independent HTTPS connection to a separate upstream instance. DID-based mutual authentication ensures only verified instances participate.
No single upstream server ever sees the complete request payload. Even if one server is fully compromised, the attacker obtains only one share -- which reveals zero information about the original data without K-1 additional shares.
DID mutual authentication replaces static API keys with cryptographic identity. Each proxy instance has an Ed25519 DID. Requests are signed and verified. No shared secrets, no config files to steal, no key rotation ceremonies.
The New Way
How It Works
Transparent HTTP proxy layer: client sends a normal request, xArmor intercepts, splits the body, fans out to upstream instances, and the reassembly proxy reconstructs the original payload before forwarding to the application.
DID mutual auth: Ed25519 identity replaces API keys. No shared secrets, no config files, no rotation needed.
Transparent to clients: Clients send normal HTTPS requests. No SDK integration required on the client side.
Use Cases
Payment request bodies split across independent processing nodes. No single node sees full card data. PCI DSS scope reduction through architectural separation.
PCI DSSPHI transmitted via split channels between healthcare systems. No single network path carries complete patient data. HIPAA compliance through information-theoretic protection.
HIPAA / HL7Classified data API requests split across independent networks. Meets separation requirements for multi-level security architectures. DID auth replaces CAC/PIV for machine-to-machine.
FISMA / FedRAMPAPI requests split across AWS, Azure, and GCP. No single cloud provider sees complete request data. Eliminates cloud vendor lock-in as a security risk.
Multi-CloudIntegration
import { createProxy, configureRoutes } from '@private.me/xarmor'; // Create split-channel proxy with 3 upstreams const proxy = await createProxy({ n: 3, k: 2, upstreams: [ 'https://us-east.api.example.com', 'https://eu-west.api.example.com', 'https://ap-south.api.example.com', ], }); // Configure which routes to split configureRoutes(proxy, { split: ['/api/payments', '/api/patients'], passthrough: ['/api/health'], });
Security Properties
| Property | Mechanism | Guarantee |
|---|---|---|
| Payload Secrecy | XorIDA split across upstreams | No single upstream sees full request |
| Machine Identity | Ed25519 DID mutual auth | Cryptographic identity, no shared secrets |
| Integrity | HMAC-SHA256 per share | Tamper detection before reconstruction |
| Fault Tolerance | K-of-N threshold | N-K upstream failures tolerated |
| Transparency | Reverse proxy pattern | No client-side changes required |
Benchmarks
Performance characteristics measured on Node.js 22, Apple M2. xArmor adds minimal latency while eliminating plaintext exposure at the proxy layer.
| Operation | Time | Notes |
|---|---|---|
| TLS termination | <1ms | Standard TLS 1.3 handshake at edge |
| XorIDA split (1 KB payload) | ~58µs | 2-of-2 threshold split over GF(2) |
| HMAC-SHA256 per share | <0.1ms | Integrity tag before routing |
| Share routing to backends | ~1–3ms | Network-dependent, parallel delivery |
| Reconstruct from shares | ~58µs | HMAC verification + XOR reconstruction |
| AES-256-GCM re-encrypt | <0.5ms | Re-encryption for downstream delivery |
| Full proxy pipeline | ~5ms | End-to-end: TLS → split → route → reconstruct → deliver |
Comparison: Traditional Proxy vs xArmor
| Property | Traditional Reverse Proxy | xArmor |
|---|---|---|
| Plaintext exposure | Full payload visible at proxy | Zero — split before routing |
| Breach impact | Complete data loss | Individual share is meaningless |
| Quantum resistance | TLS vulnerable to harvest-now | IT-secure — no keys to break |
| Added latency | ~0ms (passthrough) | ~4ms (split + route + reconstruct) |
| Audit trail | Log-based only | HMAC-chained cryptographic proof |
Ship Proofs, Not Source
xArmor generates cryptographic proofs of correct execution without exposing proprietary algorithms. Verify integrity using zero-knowledge proofs — no source code required.
- Tier 1 HMAC (~0.7KB)
- Tier 2 Commit-Reveal (~0.5KB)
- Tier 3 IT-MAC (~0.3KB)
- Tier 4 KKW ZK (~0.4KB)
Use Cases
Honest Limitations
Five known limitations documented transparently. xArmor’s security guarantees come with measurable trade-offs.
| Limitation | Impact | Mitigation |
|---|---|---|
| Latency overhead ~4ms | The split-route-reconstruct pipeline adds approximately 4ms compared to a traditional passthrough proxy. Latency-critical applications (<1ms SLA) may not tolerate this. | 4ms is imperceptible for HTTP APIs (typical response times 50–500ms). For sub-millisecond requirements, use xChange direct transport instead. |
| Multiple backends required | XorIDA 2-of-2 requires at least two independent storage/routing backends. Single-backend deployments cannot use split routing. | Cloud-native deployments naturally span availability zones. xStore provides pluggable backend adapters (local, S3, Azure Blob, custom). |
| No WebSocket support | Current implementation handles HTTP request/response only. Long-lived WebSocket connections are not split at the proxy layer. | WebSocket traffic can be routed through xChange for real-time split-channel delivery. Proxy-level WebSocket support is on the roadmap. |
| TLS termination at edge | TLS must terminate at the xArmor proxy before splitting can occur. This means the proxy momentarily holds plaintext during the split operation (~58µs). | The exposure window is 58 microseconds — orders of magnitude shorter than traditional proxies that hold plaintext for the entire request lifecycle. TEE isolation eliminates even this window. |
| Certificate management | xArmor requires its own TLS certificates separate from the origin server. Certificate rotation adds operational complexity. | Standard ACME/Let’s Encrypt automation handles certificate lifecycle. xArmor certificates can be managed alongside existing infrastructure certificates. |
Verifiable Data Protection
Every operation in this ACI produces a verifiable audit trail via xProve. HMAC-chained integrity proofs let auditors confirm that data was split, stored, and reconstructed correctly — without accessing the data itself.
Read the xProve white paper →
Ready to deploy xArmor?
Talk to Ren, our AI sales engineer, or book a live demo with our team.
Deployment Options
SaaS Recommended
Fully managed infrastructure. Call our REST API, we handle scaling, updates, and operations.
- Zero infrastructure setup
- Automatic updates
- 99.9% uptime SLA
- Enterprise SLA available
SDK Integration
Embed directly in your application. Runs in your codebase with full programmatic control.
npm install @private.me/xarmor- TypeScript/JavaScript SDK
- Full source access
- Enterprise support available
On-Premise Upon Request
Enterprise CLI for compliance, air-gap, or data residency requirements.
- Complete data sovereignty
- Air-gap capable deployment
- Custom SLA + dedicated support
- Professional services included
Enterprise On-Premise Deployment
While xArmor is primarily delivered as SaaS or SDK, we build dedicated on-premise infrastructure for customers with:
- Regulatory mandates — HIPAA, SOX, FedRAMP, CMMC requiring self-hosted processing
- Air-gapped environments — SCIF, classified networks, offline operations
- Data residency requirements — EU GDPR, China data laws, government mandates
- Custom integration needs — Embed in proprietary platforms, specialized workflows
Includes: Enterprise CLI, Docker/Kubernetes orchestration, RBAC, audit logging, and dedicated support.