Standards de chiffrement
Statut : draft à valider. Inventaire des algorithmes, protocoles et primitives cryptographiques utilisés sur la plateforme Nex.
1. Principes
- Algorithmes éprouvés uniquement : AES-GCM, RSA-OAEP, ECDH, SHA-2, bcrypt, PBKDF2, scrypt, argon2. Pas de DES, 3DES, RC4, MD5, SHA-1 pour usage cryptographique.
- Tailles de clés minimales : AES ≥ 128 bits (256 préféré), RSA ≥ 2048 bits, ECC ≥ 256 bits, hash ≥ 256 bits.
- TLS 1.2 minimum, 1.3 préféré ; 1.0 et 1.1 interdits.
- Pas de clé hard-codée dans le code, ni dans les images Docker. Voir /security/secrets-management.
2. Chiffrement en transit
TLS edge (Internet → Cloudflare)
| Aspect | Valeur |
|---|---|
| Version min | TLS 1.2 (cf. ADR-0010) |
| Mode SSL Cloudflare | Full (strict) |
| Always Use HTTPS | ON |
| Cipher suites | gérés par Cloudflare, suites modernes uniquement |
| HSTS | [À CONFIRMER : header HSTS posé ?] |
TLS origin (Cloudflare → NLB AWS → Ingress NGINX → pods)
| Aspect | Valeur |
|---|---|
| Cert origin | Let's Encrypt via cert-manager (renouvellement automatique) |
| ClusterIssuer | letsencrypt-prod (READY) |
| Renouvellement | automatique à J-30 |
| mTLS inter-pods K8s | [À CONFIRMER : pas actif aujourd'hui, à évaluer pour scope audit] |
Communication mobile → API
- TLS 1.2+ obligatoire.
- Pas de SSL pinning mobile aujourd'hui — cf. /security/known-gaps.
Communication backend → providers externes
| Provider | Protocole |
|---|---|
| Firebase (Auth, Storage, Messaging) | HTTPS TLS 1.2+ (géré par SDK) |
| Apentis | HTTPS [À CONFIRMER version min] |
| Mobile Money operators | Hétérogène (REST HTTPS, USSD via gateway, batch via SFTP) — à documenter dans /services/providers-gateway/ |
| Doppler API | HTTPS TLS 1.3 |
3. Chiffrement au repos
| Stockage | Encryption | Algorithme | Notes |
|---|---|---|---|
| RDS PostgreSQL (prod & staging) | [À CONFIRMER activée] | AES-256 (RDS encryption) | À valider explicitement |
| Redis ElastiCache | [À CONFIRMER] | AES-256 | |
| Firebase Cloud Storage | ✅ géré par Firebase | AES-256 | par défaut |
| Doppler (secrets) | ✅ géré par Doppler | AES-256 | |
| EBS volumes (EKS nodes) | [À CONFIRMER] | AES-256 | par défaut sur EKS depuis 2023 |
| Backups RDS | [À CONFIRMER] | AES-256 | doit être chiffré |
À documenter / vérifier explicitement pour fournir l'évidence aux audits. Marqué comme gap dans known-gaps si non confirmé.
4. Primitives par usage métier
Authentification utilisateur
| Élément | Algorithme | Paramètres | Code |
|---|---|---|---|
| Hash PIN serveur | bcrypt | rounds = [À CONFIRMER, default Nest 10-12] | services/auth/src/auth/pin-security.service.ts [À VÉRIFIER nom exact] |
| Dérivation PIN mobile (offline) | PBKDF2-SHA256 | iterations / salt / hash : voir constantes @nex/mobile-auth | packages/mobile-auth/src/services/pinVault.ts |
| Hash OTP serveur | bcrypt | (avant verify en compare) | services/auth/src/auth/otp.service.ts |
| Token Redis (sessions) | SHA-256 (non-réversible) | n/a | services/auth/src/redis/redis.service.ts |
| Custom token client | Firebase RS256 | géré par Firebase Admin SDK | ADR-0002 |
| JWT internal-service | HS256 ou RS256 [À CONFIRMER] | clé signing dans Doppler | inter-services |
QR code sécurisé
Voir /security/qr-code et ADR-0013.
| Élément | Algorithme | Notes |
|---|---|---|
| Chiffrement payload QR | AES-256-GCM | confidentialité + intégrité + auth dans une seule primitive |
| Device key | AES-256 (32 bytes hex 64 chars) | générée à l'enrôlement, stockée en qr_device_keys |
| Nonce | 16 bytes random | anti-replay par-token |
| Tag auth GCM | 16 bytes | vérifié à la résolution → rejet si invalide |
Inter-services
| Élément | Algorithme |
|---|---|
JWT scope internal-service-jwt, risk:evaluate, etc. | RS256 [À CONFIRMER signing] |
| Vérification | clé publique partagée via JWKS Firebase ou JWKS interne [À CONFIRMER] |
5. Gestion des clés
| Type de clé | Stockage | Rotation | Owner |
|---|---|---|---|
| Clés JWT signing | Doppler (prd config) | 180 j cible [À OPÉRATIONNALISER] | @platform-team |
| Firebase service account keys | Doppler + Firebase | 12 mois | @platform-team |
| Device keys QR (AES-256) | DB Postgres qr_device_keys, par appareil | révocation possible à tout moment | @security-team |
| API keys providers | Doppler par provider | selon contrat provider | @platform-team |
| TLS certs origin | cert-manager + AWS / Cloudflare | automatique | @platform-ops |
| Clés SSH ops | hardware (Yubikey / TPM) ou fichier chiffré | 12 mois | individuel |
Pas de HSM ni KMS dédié aujourd'hui — toutes les clés vivent dans Doppler. À évaluer pour scope audit ou si scope PCI activé.
6. Algorithmes interdits
| Algorithme | Pourquoi |
|---|---|
| DES, 3DES | Faiblesses cryptographiques |
| RC4 | Faiblesses cryptographiques |
| MD5 | Collisions triviales (sauf usage strictement non-sécurité, ex : ETag HTTP) |
| SHA-1 | Collisions démontrées (sauf usage non-sécurité) |
| TLS 1.0, 1.1 | Vulnérabilités, dépréciés par IETF |
| ECB mode (AES) | Pattern visible dans le ciphertext |
Génération de "random" via Math.random() | Non-cryptographique. Utiliser crypto.randomBytes ou Web Crypto API |
7. Génération d'aléa
- Backend :
crypto.randomBytes()(Node.js). - Mobile :
react-native-quick-crypto(JSI natif, mêmes primitives que Node.js). - Web :
window.crypto.getRandomValues().
8. Bonnes pratiques code
- Comparaisons de secrets en temps constant (
crypto.timingSafeEqualou équivalent). Cf. le middleware Basic Auth dansapps/docs/functions/_middleware.jsqui implémente le pattern. - IV uniques pour chaque opération AES-GCM. Ne jamais réutiliser un IV avec une même clé.
- Validation des tag GCM : rejet strict si vérification échoue.
- Pas de fallback silencieux vers un algo plus faible (ex : si AES-GCM échoue, ne pas essayer CBC).
- Erreurs cryptographiques : message générique côté client, détail dans les logs serveur uniquement.
9. Conformité
| Cadre | Exigence | État Nex |
|---|---|---|
| PCI-DSS Req 3.4 (si scope card) | Chiffrement at-rest des données titulaires | À évaluer si scope card actif |
| PCI-DSS Req 4.1 | TLS pour data en transit publique | ✅ TLS 1.2+ partout |
| ISO 27001 Annex A.8.24 | Gestion clés cryptographiques | partiel ; rotation à formaliser |
| OWASP ASVS 6.x (Stored Cryptography) | Niveau 2 fintech | partiel ; gap analysis à faire |
| OWASP MASVS-CRYPTO | Mobile crypto | partiel ; PBKDF2 OK, mais clés DB clear ? [À CONFIRMER] |
10. Gaps connus
- Encryption at-rest RDS / Redis / EBS : statut à confirmer explicitement.
- HSTS strict + preload : à valider côté Cloudflare.
- Rotation des secrets : procédures non formalisées (cf. secrets-management).
- SSL pinning mobile absent.
- mTLS inter-services K8s absent (mais segmentation NetworkPolicy en place).
- Pas de HSM/KMS dédié pour les clés critiques.
Cf. /security/known-gaps.