Encryption & TLS
How AfriRoute protects data in transit and at rest. Encryption is applied at every layer, with modern algorithms and managed key rotation.
🔒 Encryption in Transit
| Connection | Protection |
|---|---|
| Client → API | TLS 1.3 (TLS 1.2 minimum), HSTS enforced |
| Service → Service | mutual TLS (mTLS) via service mesh |
| Service → Database | TLS-required connections |
| Worker → Carrier | TLS where supported; IPsec/private links otherwise |
| Webhooks (outbound) | HTTPS only + HMAC body signature |
- TLS 1.3 preferred, 1.2 minimum; SSLv3/TLS 1.0/1.1 are disabled.
- Only strong cipher suites are negotiated (AEAD:
TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256). - HTTP is rejected — there is no plaintext listener on the API.
# HTTP is refused; only HTTPS is served
curl http://api.afriroute.ai/api/v1/sms/send # connection refused / redirected
🗄️ Encryption at Rest
| Data Store | Encryption |
|---|---|
| PostgreSQL | AES-256 volume + transparent data encryption |
| Object storage (recordings, ID images) | AES-256, server-side, per-object keys |
| Redis | AES-256 at rest; sensitive values not persisted |
| Backups | AES-256 with separate backup keys |
| Secrets (Vault) | AES-256-GCM, sealed with KMS root key |
All storage is encrypted by default; there is no path to write unencrypted customer data.
🔑 Key Management
Keys are managed in a cloud KMS / HSM (FIPS 140-2 Level 3 backed). AfriRoute uses envelope encryption: data is encrypted with a per-object data key, which is itself encrypted by a KMS-held master key.
flowchart LR
KMS[(KMS Master Key\nHSM-backed)] -->|wraps| DEK[Data Encryption Key]
DEK -->|encrypts| DATA[(Customer Data)]
KMS -.rotation.-> KMS
| Property | Policy |
|---|---|
| Master key rotation | Annual (or on demand) |
| Data key rotation | Per object / per envelope |
| Access | KMS access is IAM-scoped + audited |
| Separation | Backup keys are distinct from production keys |
🧬 Field-Level Encryption for Sensitive Data
Highly sensitive fields receive an extra layer of application-level encryption beyond at-rest disk encryption:
- Biometric & identity data (face embeddings, ID images) — encrypted with dedicated keys, access logged per read.
- Payment instrument data — handled under PCI DSS scope; PANs are tokenized, never stored in the clear.
- Webhook secrets & API key hashes — stored hashed/encrypted, never reversible to plaintext.
✍️ Integrity & Signing
- Webhooks are HMAC-SHA256 signed so recipients can detect tampering.
- Container images are signed before release, and unsigned images are blocked from production admission.
- Audit logs are hash-chained for tamper evidence.
📜 Certificate Management
- Public TLS certificates are issued via ACME and auto-renewed well before expiry.
- Internal mesh certificates are short-lived and rotated automatically by the service mesh.
- Certificate expiry is monitored; alerts fire on any cert within its renewal window.
✅ What This Means for Integrators
- Always call
https://endpoints — HTTP will fail. - Verify the AfriRoute TLS certificate chain (no certificate pinning required, but recommended for mobile).
- Keep your webhook secret confidential; rotate it from the dashboard if exposed.
📚 Related Documentation
Last Updated: May 2026