Security
How Archangel protects applications, licenses, and client communications.
Cryptographic Signing
Every API response from Archangel is signed using Ed25519. The server holds the private key; client applications embed only the public key and verify each response signature before trusting any data. This prevents man-in-the-middle attacks and response tampering.
Even an attacker who intercepts traffic between the client and server cannot forge a valid response without the private key. Any modification to the response payload invalidates the signature, and the client rejects it.
Asymmetric Key Design
Each application receives its own Ed25519 keypair upon creation. The public key is safe to distribute with client builds: it can only verify signatures, never create them. Extracting the key from a compiled binary does not compromise the system.
If a key is suspected to be compromised, key rotation is available from the application settings in the dashboard. Rotating the key invalidates the previous public key, requiring a client update.
Encrypted Channel
On top of TLS, Archangel supports an end-to-end encrypted channel. A client can opt in during initialization by performing an X25519 key exchange with the server, which derives a unique AES-256-GCM key for that session. Sensitive payloads then stay opaque even to intercepting proxies, and the signature covers the encrypted data itself.
Hardware Binding
Licenses are bound to hardware fingerprints to prevent key sharing. The client machine computes a composite fingerprint from multiple hardware components, hashes it with SHA-256, and sends only the hash during authentication.
Archangel tracks bound devices per license and enforces configurable device limits. Individual hardware components are scored rather than matched exactly, so a legitimate upgrade does not lock a customer out while a different machine is still rejected. Once a license reaches its device cap, authentication from new hardware is refused until a binding is released.
Session Integrity
Sessions are protected by a challenge and response scheme. Every response issues a fresh nonce that the client must present on its next request, which defeats replayed traffic. Sessions expire after 24 hours of inactivity, and per-user concurrency limits evict the oldest session when exceeded.
Rate Limiting
All client API endpoints are rate-limited per IP address to prevent abuse and brute-force attempts.
| Endpoint | Limit |
|---|---|
| Authentication | 10 requests / minute |
| Heartbeat | 60 requests / hour |
| File / Init | 5 requests / minute |
Exceeding the limit returns HTTP 429 Too Many Requests with a Retry-After header indicating how long to wait before retrying.
Anomaly Detection
Archangel performs behavioral analysis on authentication patterns to detect suspicious activity. The following signals are monitored:
- Velocity spikes: unusually high authentication frequency from a single license
- Hardware fingerprint changes: rapid HWID switching that indicates key sharing
- Clock manipulation: timestamp anomalies suggesting a tampered system clock
- Impossible travel: logins from locations too far apart for the elapsed time
Each detection type supports configurable responses: logging only, automatic suspension, or automatic banning. Alerts can be delivered in real time via Discord or Telegram, configured per application in the dashboard.
POST-Only API
The client API accepts only POST requests. This keeps authentication data such as license keys, hardware identifiers, and session tokens out of URL query strings, browser history, server access logs, and CDN caches.
Note
All request and response bodies use JSON, and every response is signed before it leaves the server.