🔐 Cryptography & Trust Engineering for AI Cyber Defense

Ce qu’un modèle doit extraire d’un certificat

Un certificat X.509 transporte bien plus qu’un nom de domaine. Il contient un ensemble de champs qui déterminent son usage, sa validité, sa chaîne de confiance et sa robustesse cryptographique.

Commande de lecture défensive

# Inspection locale d’un certificat fourni par l’équipe interne
openssl x509 -in server.crt -noout -text

# Vérifier subject, issuer, SAN, KU/EKU, dates, algorithme de signature
# Ne pas collecter de clé privée dans un outil IA.

Extraction structurée attendue

{
  "asset": "api.example.com",
  "issuer": "Example Intermediate CA",
  "san": ["api.example.com", "api.internal.example.com"],
  "not_after": "2026-11-12",
  "key_algorithm": "ECDSA P-256",
  "signature_algorithm": "sha256WithECDSA",
  "eku": ["serverAuth"],
  "findings": [
    "OCSP stapling not observed",
    "expiration monitoring required"
  ]
}

Pourquoi la chaîne casse souvent en production

Les incidents TLS/PKI les plus fréquents ne viennent pas de mathématiques cassées, mais d’exploitation : intermédiaire oublié, certificat expiré, SAN incomplet, trust store différent entre environnements, ou renouvellement manuel raté.

• Un certificat leaf est renouvelé mais l’intermédiaire n’est pas servi par Nginx.
• Un service interne fait confiance à une ancienne CA supprimée du trust store.
• Un certificat wildcard couvre trop de services et complique l’isolation.
• Un client mTLS utilise un EKU inadapté ou une CA trop large.
• Une chaîne passe sur un navigateur mais échoue sur Java, Python ou un équipement réseau.

# Vérifier la chaîne servie par un endpoint interne autorisé
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts

# Points à vérifier :
# - Le serveur renvoie-t-il la chaîne complète ?
# - Le certificat leaf correspond-il au SNI ?
# - L’intermédiaire est-il correct ?
# - Les dates et l’algorithme sont-ils acceptables ?

Incident typique

Renouvellement certificat
  ↓
Leaf installé
  ↓
Intermediate oublié
  ↓
Certains clients acceptent via cache
  ↓
Clients Java / mobile / IoT échouent
  ↓
Incident intermittent difficile à diagnostiquer

Solution :
inventaire + automation + test multi-clients + monitoring.

Révocation : souvent mal comprise

Révoquer un certificat ne signifie pas toujours que tous les clients le rejetteront immédiatement. CRL, OCSP, OCSP stapling et certificats courts ont des comportements variables selon clients, politiques et disponibilité réseau.

Clé privée soupçonnée compromise
  ↓
Identifier certificats associés
  ↓
Révoquer via CA
  ↓
Vérifier publication CRL/OCSP
  ↓
Déployer certificat remplacant
  ↓
Tester clients critiques
  ↓
Journaliser l’incident
  ↓
Mettre à jour inventaire et postmortem

Comment utiliser un modèle type Mythos-like

Le modèle peut relire une exportation d’inventaire, des outputs OpenSSL, la configuration Nginx, les policies de CA internes et les tickets d’incident. Il doit produire une analyse structurée : preuve → risque → correction → validation.

Prompt défensif :

Voici un inventaire de certificats, une configuration Nginx et des outputs openssl.
1. Identifie les certificats proches expiration.
2. Détecte SAN manquants, algorithmes faibles, EKU incohérents.
3. Signale les chaînes incomplètes.
4. Classe les risques selon exposition et criticité métier.
5. Propose un plan de correction et des tests.
6. Ne suppose rien sans preuve ; indique les incertitudes.

Format de finding attendu

Finding: Intermediate certificate not served
Evidence:
- openssl s_client output: verify return code 21
- nginx ssl_certificate points to leaf only
Impact:
- Certains clients ne peuvent pas valider la chaîne.
- Risque d’indisponibilité partielle.
Remediation:
- Installer fullchain.pem.
Validation:
- openssl s_client with SNI.
- Test Java client.
- Monitoring synthetic check.
Residual risk:
- Faible après automation du renouvellement.

Checklist opérationnelle

• Inventaire complet des certificats publics, internes et mTLS.
• Owner métier et owner technique pour chaque certificat.
• Alerte à J-60, J-30, J-14, J-7 et J-1 avant expiration.
• Chaîne complète vérifiée avec SNI.
• SAN corrects, pas de CN legacy comme seule source d’identité.
• EKU cohérent avec l’usage : serverAuth, clientAuth, codeSigning.
• Algorithmes modernes : SHA-256 ou mieux, clés conformes aux politiques.
• Procédure de révocation testée au moins une fois par an.
• Pas de clé privée dans Git, tickets, logs, prompts ou exports non chiffrés.
• Runbook de rotation d’urgence documenté.

Questions d’entretien

1. Pourquoi un certificat valide peut-il échouer sur certains clients ?
2. Quelle différence entre root CA, intermediate CA et leaf certificate ?
3. Pourquoi le SAN est-il critique ?
4. Comment testeriez-vous un incident d’intermédiaire manquant ?
5. Quand choisir mTLS plutôt qu’un simple bearer token ?
6. Comment gérer une clé privée compromise ?

Durcissement sans dogmatisme

Une configuration TLS doit être moderne, mais aussi compatible avec les clients réels. Le rôle d’un modèle IA est d’identifier les options dangereuses, les incohérences et les écarts par rapport à la politique de l’entreprise.

# Exemple indicatif à adapter et tester, pas à coller aveuglément
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Tests à intégrer en CI ou monitoring

Le test TLS ne doit pas être manuel tous les six mois. Il doit être automatisé en préproduction, en production et lors de chaque renouvellement majeur.

# Vérifier handshake, SNI et chaîne
openssl s_client -connect example.com:443 -servername example.com -showcerts

# Vérifier dates du certificat
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -dates -issuer -subject

# Test synthétique côté applicatif
curl -Iv https://example.com/

• Tester depuis plusieurs réseaux si CDN, WAF ou reverse proxies.
• Tester clients critiques : Java, Python, mobile, équipements legacy.
• Vérifier HTTP vers HTTPS, HSTS et absence de mixed content.
• Mettre une alerte avant expiration et après renouvellement.

Déploiement TLS
  ↓
Test openssl
  ↓
Test curl
  ↓
Test client applicatif réel
  ↓
Test monitoring externe
  ↓
Validation logs Nginx / ALB
  ↓
Ticket clôturé avec preuves

Incidents typiques et diagnostic

Ce que l’IA doit produire

• Hypothèses classées par probabilité.
• Commandes de validation défensive.
• Risques opérationnels associés.
• Remédiation avec rollback.
• Message clair pour support et management.

Finding: HSTS includeSubDomains enabled while legacy subdomain remains HTTP-only
Evidence:
- Response header on apex domain includes includeSubDomains.
- legacy.example.com does not serve valid HTTPS.
Impact:
- Browsers may refuse access after HSTS caching.
Remediation:
- Enable HTTPS on legacy subdomain or remove includeSubDomains until ready.
Validation:
- Browser clean profile + curl + synthetic monitoring.

mTLS : identité machine à machine

mTLS ajoute une authentification du client par certificat. C’est puissant pour service-to-service, mais demande une discipline opérationnelle : émission, distribution, rotation, révocation, mapping d’identité et logs.

• Utiliser une CA dédiée aux clients mTLS, pas la même que les certificats publics.
• Limiter les EKU à clientAuth pour les certificats clients.
• Mapper l’identité certificat vers un service, pas vers un humain générique.
• Définir une durée de vie courte si l’automation le permet.
• Journaliser subject/SAN/serial sans exposer de données inutiles.

Service A
  présente client certificate
        ↓
Gateway / Service B
  vérifie CA + EKU + identité
        ↓
Policy mapping
  subject/SAN → service identity
        ↓
Autorisation
  service A peut appeler endpoint X

Checklist rapide

• TLS 1.0/1.1 désactivés sauf contrainte documentée.
• TLS 1.3 activé si stack compatible.
• Chaîne complète servie avec SNI.
• Certificats surveillés et renouvelés automatiquement.
• HSTS activé progressivement, includeSubDomains seulement après inventaire.
• OCSP stapling évalué et testé si utilisé.
• Pas de clés privées dans tickets, prompts ou dépôts.
• Tests multi-clients après chaque changement.
• Runbook d’expiration et rollback disponible.

Questions d’entretien

1. Expliquez la différence entre TLS 1.2 et TLS 1.3 côté handshake.
2. Pourquoi fullchain.pem est-il important ?
3. Quels risques liés à HSTS includeSubDomains ?
4. Comment diagnostiquer une erreur TLS uniquement côté Java ?
5. Quand utiliser mTLS ?

Ce qu’une API doit valider

# Pseudo-code défensif
token = parse_authorization_header(request)
claims = jwt_library.verify(
    token,
    jwks=trusted_jwks,
    allowed_algorithms=["RS256", "ES256"],
    issuer="https://idp.example.com/",
    audience="api://orders"
)
require_scope(claims, "orders:read")

Validation JWT robuste
  ↓
1. Extraire Bearer token
2. Vérifier signature
3. Vérifier algorithme autorisé
4. Vérifier issuer
5. Vérifier audience
6. Vérifier dates
7. Vérifier scopes/roles
8. Appliquer autorisation métier

Erreurs que l’IA peut repérer dans le code

Exemple de finding défensif

Finding: Audience claim not enforced
Evidence:
- Auth middleware verifies signature but does not check aud.
- API expects tokens for api://orders.
Impact:
- A token issued for another service may be accepted.
Remediation:
- Configure JWT verifier with strict audience.
Validation:
- Unit test rejects token with wrong aud.

Anti-patterns côté architecture

• Multiplier les middlewares maison dans plusieurs services.
• Copier des secrets JWT dans variables d’environnement non gérées.
• Confondre authentification et autorisation.
• Utiliser des tokens trop longs sans rotation ou revocation strategy.
• Absence de logs utiles sur rejets de tokens.

Rotation des clés de signature

La rotation JWKS doit être conçue pour éviter deux incidents opposés : accepter indéfiniment de vieilles clés, ou casser l’API au moment de la rotation.

• Les tokens existants peuvent rester valides jusqu’à expiration.
• Les backends doivent rafraîchir JWKS avec cache maîtrisé.
• Le kid doit permettre d’identifier la bonne clé.
• Les clés retirées trop tôt provoquent des erreurs 401 massives.
• Les clés conservées trop longtemps augmentent le risque résiduel.

Rotation JWKS
  ↓
1. Publier nouvelle clé
2. Commencer à signer avec nouvelle clé
3. Laisser expirer tokens signés ancienne clé
4. Retirer ancienne clé
5. Vérifier taux 401 et logs

Ne pas confondre les rôles

Un moteur IA doit vérifier que l’API ne traite pas n’importe quel token comme preuve d’identité. L’audience et l’usage du token sont essentiels.

Mauvaise architecture
ID token → API backend → accès ressources

Architecture attendue
Access token destiné à l’API
  ↓
Vérification signature + aud + scopes
  ↓
Autorisation métier

Tests défensifs à écrire

• Rejeter un token expiré.
• Rejeter un token avec mauvais issuer.
• Rejeter un token avec mauvaise audience.
• Rejeter un token signé par une clé inconnue.
• Rejeter un token avec scope insuffisant.
• Accepter uniquement algorithmes explicitement configurés.
• Vérifier que les erreurs ne révèlent pas de détails sensibles.
• Tester rotation JWKS en préproduction.

# Exemple de test conceptuel
def test_reject_wrong_audience(api_client, token_factory):
    token = token_factory(aud="api://billing")
    response = api_client.get("/api/orders", headers={"Authorization": "Bearer " + token})
    assert response.status_code == 401

Checklist audit IA

Choisir le bon niveau de protection

Ce que l’IA peut vérifier

• Les workloads ont-ils seulement accès aux secrets nécessaires ?
• Les clés KMS sont-elles séparées par environnement ?
• Les politiques permettent-elles un accès wildcard dangereux ?
• Les rotations sont-elles réellement activées ou seulement documentées ?

Exemple de finding défensif :

Finding: Production deployment role can read all secrets in account
Evidence:
- IAM policy contains secretsmanager:GetSecretValue on resource "*"
Impact:
- Compromise of CI/CD role exposes database, API and signing secrets.
Remediation:
- Restrict policy to explicit secret ARNs per application.
Validation:
- IAM access analyzer + integration test deploy.

Le pipeline est un coffre-fort exposé

Un pipeline CI/CD peut construire, signer, publier et déployer. S’il contient des secrets trop puissants, la compromission du pipeline devient une compromission de production.

• Utiliser OIDC federation vers cloud plutôt que clés statiques longues.
• Limiter les secrets par environnement : dev, staging, prod.
• Éviter les secrets dans logs de build.
• Empêcher les workflows de forks non fiables d’accéder aux secrets.
• Vérifier les permissions GitHub Actions ou GitLab CI.

Developer push
  ↓
CI workflow
  ↓
Build artifact
  ↓
Registry
  ↓
Deploy role
  ↓
Production

Question défense :
Quelle identité peut lire quels secrets à chaque étape ?

Planifier la rotation avant l’incident

La rotation ne doit pas être improvisée pendant une fuite. Elle doit être testée avec double publication, période de chevauchement, rollback et validation applicative.

Rotation sûre

1. Créer nouveau secret
2. Déployer application capable de lire nouveau + ancien
3. Basculer production vers nouveau
4. Vérifier logs et métriques
5. Révoquer ancien secret
6. Confirmer qu’aucun client ne l’utilise

Runbook en cas de fuite

1. Identifier le secret et son périmètre exact.
2. Révoquer ou désactiver immédiatement si possible.
3. Créer un secret de remplacement.
4. Déployer la configuration corrigée.
5. Rechercher usages suspects dans logs.
6. Nettoyer dépôts, tickets et artefacts, mais ne pas croire que l’historique supprimé suffit.
7. Documenter l’incident et améliorer les contrôles.

Détection sans exfiltrer

Un agent IA ne doit pas collecter des secrets bruts. Il peut recevoir des métadonnées : type détecté, chemin, commit, date, statut actif/inactif, propriétaire, environnement.

Entrée autorisée vers l’IA :
{
  "type": "AWS_ACCESS_KEY_ID",
  "file": "settings.py",
  "line": 42,
  "secret_redacted": "AKIA************",
  "commit_date": "2026-07-09",
  "environment": "unknown",
  "active_status": "not_tested"
}

Entrée interdite :
la clé complète, le secret complet, un dump .env complet.

Checklist secrets

• Aucun secret dans Git, Dockerfile, logs, tickets, prompts.
• Secrets par environnement et par service.
• IAM minimal pour accéder aux secrets.
• Rotation testée et documentée.
• Détection pré-commit et côté serveur.
• Logs de consultation des secrets activés.
• Procédure de révocation d’urgence disponible.
• OIDC CI/CD préféré aux clés cloud statiques.
• Pas de clé privée envoyée à un modèle IA.
• Revue régulière des secrets orphelins.

Questions d’entretien

1. Pourquoi supprimer un secret de Git ne suffit-il pas ?
2. Comment organiser une rotation sans downtime ?
3. Différence entre KMS, HSM et secrets manager ?
4. Comment empêcher un workflow CI de lire les secrets prod ?
5. Quelles métadonnées peut-on envoyer à un modèle IA sans fuite ?

Authenticated Encryption with Associated Data

AEAD fournit confidentialité et intégrité. On peut aussi authentifier des données non chiffrées mais liées au message : version, tenant, user id, contexte de protocole.

• Le ciphertext seul ne suffit pas ; le tag d’authentification est indispensable.
• Le nonce doit être unique pour une clé donnée.
• L’AAD doit être identique lors du chiffrement et du déchiffrement.
• Une erreur de tag doit être traitée comme échec de sécurité, pas comme simple bug.

# Pseudo-code conceptuel
nonce = secure_random_96_bits()
aad = "tenant=acme;purpose=session-v1"
ciphertext, tag = aead_encrypt(key, nonce, plaintext, aad)

# À stocker/transmettre :
version || key_id || nonce || aad_id || ciphertext || tag

Le piège numéro 1 : la réutilisation

Dans beaucoup de modes modernes, réutiliser un nonce avec la même clé peut être catastrophique. L’IA doit rechercher les patterns de nonce constant, compteur mal initialisé, random insuffisant ou valeurs dérivées prédictibles.

Finding: Constant IV used for AES-GCM
Evidence:
- crypto.py line 87: iv = b"000000000000"
Impact:
- Reuse with same key can break confidentiality/integrity guarantees.
Remediation:
- Generate unique 96-bit nonce per encryption.
- Store nonce with ciphertext.
Validation:
- Unit test encrypts 10,000 messages and verifies nonce uniqueness.

HMAC : intégrité et authenticité

HMAC protège l’intégrité d’un message avec une clé secrète partagée. Il est utile pour webhooks, signatures de requêtes, messages internes ou tokens simples. Il ne chiffre pas.

• Utiliser SHA-256 ou mieux selon politique.
• Comparer avec une fonction constant-time.
• Inclure méthode, path, body hash, timestamp et nonce dans la chaîne signée si protocole maison.
• Limiter la fenêtre temporelle pour éviter rejeu.
• Préférer des protocoles standards quand possible.

Webhook sécurisé

Provider
  calcule HMAC(secret, timestamp + body)
        ↓
Envoie body + timestamp + signature
        ↓
Backend
  vérifie timestamp récent
  recalcule HMAC
  compare constant-time
  traite seulement si valide

Ne jamais chiffrer les mots de passe

Les mots de passe doivent être hachés avec une fonction dédiée lente et salée : Argon2id, bcrypt ou PBKDF2 selon contexte et contraintes. AES/HMAC/SHA-256 seul ne sont pas des solutions de stockage de mots de passe.

Finding: Passwords hashed with raw SHA-256
Impact:
- Fast hash enables large-scale offline guessing if DB leaks.
Remediation:
- Migrate to Argon2id/bcrypt/PBKDF2 with per-user salt.
- Rehash on next successful login.
Validation:
- New accounts use strong password hashing.
- Old hashes migrate progressively.

Checklist chiffrement symétrique

• Ne pas implémenter son propre algorithme.
• Utiliser une librairie maintenue.
• Préférer AEAD.
• Nonce unique par clé et message.
• Key id inclus pour rotation.
• Clés dans KMS/Vault/HSM selon criticité.
• Pas de plaintext en logs.
• Pas de mot de passe stocké par chiffrement réversible.
• Tests de non-régression crypto.
• Documentation du format de message chiffré.

Prompt de revue IA

Analyse ce module de chiffrement applicatif.
Repère seulement les mauvaises pratiques défensives :
- mode dangereux
- nonce/IV réutilisé
- absence d’authentification
- clés hardcodées
- logging de données sensibles
- password hashing incorrect
Retourne preuves, impact, patch recommandé et tests.

Courbes modernes

ECC permet des clés plus petites et de bonnes performances. Ed25519 est courant pour signatures modernes, X25519 pour échange de clés. En entreprise, la compatibilité clients et l’écosystème doivent guider la migration.

Choix défensif
  ↓
Compatibilité clients
  ↓
Bibliothèque maintenue
  ↓
Politique algorithmes
  ↓
Key management
  ↓
Tests interop
  ↓
Migration progressive

Ne pas confondre les usages

Signer n’est pas chiffrer. Chiffrer n’authentifie pas toujours. Établir une clé n’est pas signer. Un modèle IA doit détecter ces confusions dans les designs et les revues de code.

Exemple de conclusion IA attendue :
Le module utilise RSA pour chiffrer directement un payload applicatif volumineux.
Recommandation : utiliser un schéma hybride standard :
- générer une clé symétrique par message
- chiffrer le payload avec AEAD
- protéger la clé selon KMS/protocole standard

Clés SSH : identité opérationnelle critique

Les clés SSH donnent souvent accès aux serveurs et pipelines. L’audit doit vérifier type de clé, passphrase, stockage, rotation, agents, comptes partagés et logs.

• Éviter comptes partagés et clés sans propriétaire.
• Préférer clés modernes supportées par l’environnement.
• Protéger clés privées par passphrase ou hardware key.
• Désactiver clés orphelines.
• Documenter accès break-glass séparément.

La migration est un projet, pas une ligne de config

Changer d’algorithme peut casser des clients, appliances, bibliothèques, partenaires et systèmes legacy. L’IA peut aider à construire l’inventaire et simuler les impacts.

Inventaire algorithmes
  ↓
Classer par actif et criticité
  ↓
Identifier clients incompatibles
  ↓
Créer mode dual-stack
  ↓
Tester préproduction
  ↓
Déployer progressivement
  ↓
Retirer algorithme legacy
  ↓
Documenter risque résiduel

Prompt de revue asymétrique

Analyse cette configuration crypto asymétrique.
Pour chaque clé/certificat/usage :
- identifie l’usage réel : signature, chiffrement, key exchange, SSH, TLS
- vérifie taille, algorithme, dates, owner, stockage
- repère confusion d’usage
- propose migration prudente
- liste tests d’interop et rollback

Checklist

• Inventaire clés publiques/privées.
• Owner technique.
• Algorithme et taille conformes.
• Usage documenté.
• Clé privée protégée.
• Rotation et révocation possibles.
• Tests de compatibilité.
• Suppression des clés orphelines.
• Pas de private key dans IA, logs ou tickets.

Crypto inventory

Un inventaire post-quantique doit couvrir TLS, VPN, SSH, PKI, code signing, JWT, S/MIME, bases de données, archives, backups, KMS, HSM, librairies et protocoles partenaires.

Entrée IA structurée :
asset, protocol, algorithm, key_size, library, owner,
data_classification, confidentiality_lifetime, external_dependency,
migration_blockers, test_environment

Familles à connaître

Les standards post-quantiques modernes distinguent principalement encapsulation de clés, signatures et signatures stateless hash-based. Le guide doit rester prudent sur les noms exacts selon adoption fournisseur, mais les familles sont essentielles.

Transition plausible

Classique uniquement
  ↓
Hybrid classique + PQC
  ↓
PQC standardisé + interop validée
  ↓
Retrait progressif des primitives vulnérables

Pourquoi hybride ?

L’hybridation combine un mécanisme classique éprouvé avec un mécanisme post-quantique. L’objectif est de réduire le risque tout en conservant la sécurité si l’un des mécanismes se révèle fragile pendant la transition.

• Tester compatibilité clients, proxies, WAF, CDN et observabilité.
• Mesurer impact taille handshake, latence et CPU.
• Déployer d’abord sur services pilotes.
• Surveiller erreurs handshake et fallback.
• Documenter les clients incompatibles.

Roadmap réaliste

1. Mois 1-3 : inventaire crypto et classification des données.
2. Mois 3-6 : identifier actifs à confidentialité longue.
3. Mois 6-9 : vérifier support vendor, librairies et HSM/KMS.
4. Mois 9-12 : pilotes hybrides sur services non critiques.
5. Mois 12-15 : procédures de rotation et tests d’interop.
6. Mois 15-18 : déploiement progressif sur services prioritaires.

PQC readiness
  ↓
Inventory
  ↓
Risk classification
  ↓
Vendor readiness
  ↓
Pilot hybrid
  ↓
Operational runbooks
  ↓
Progressive migration

Ce qu’un modèle peut faire utilement

• Extraire usages crypto dans code et configs.
• Construire une matrice actif → algorithme → owner → criticité.
• Repérer dépendances non maintenues.
• Comparer support des bibliothèques.
• Générer une roadmap et des tickets de migration.
• Rédiger une note exécutive claire.

Prompt :
À partir de cet inventaire d’actifs et de dépendances, produis une matrice PQC readiness.
Priorise selon durée de confidentialité, exposition, contraintes vendor et criticité métier.
Ne recommande pas de migration en production sans phase pilote et tests d’interop.

Questions d’entretien

1. Qu’est-ce que harvest now, decrypt later ?
2. Pourquoi l’inventaire crypto précède le choix d’algorithme ?
3. Pourquoi utiliser une approche hybride ?
4. Quels actifs prioriser pour PQC ?
5. Quels risques opérationnels pendant migration ?

Points de contrôle Java

Finding défensif :
- Classe: InsecureTrustManager
- Méthode: checkServerTrusted ne valide rien
- Impact: le client accepte tout certificat
- Remédiation: utiliser truststore géré ou CA interne explicite
- Test: certificat non approuvé doit échouer

Revue Java crypto
  ↓
Truststore / keystore
  ↓
TLS clients
  ↓
JWT validation
  ↓
Password hashing
  ↓
Cipher modes
  ↓
Secrets in config
  ↓
Tests unitaires et intégration

Risques fréquents

• NODE_TLS_REJECT_UNAUTHORIZED=0.
• JWT vérifié sans issuer/audience.
• Tokens stockés en localStorage dans contexte XSS non maîtrisé.
• Crypto Node utilisée sans authentification.
• Secrets dans bundle frontend.
• Webhook HMAC comparé avec simple ==.

# Finding attendu
Environment variable disables TLS verification:
NODE_TLS_REJECT_UNAUTHORIZED=0

Remediation:
- Remove this variable.
- Install internal CA in runtime image.
- Add integration test against untrusted certificate.

Catalogue défensif

Finding crypto code
  ↓
Preuve précise
  ↓
Pourquoi c’est risqué
  ↓
Correction minimale
  ↓
Test automatisé
  ↓
PR + revue humaine

Template de Pull Request

Title: Harden JWT audience validation

Problem:
The API validates token signature but does not enforce expected audience.

Evidence:
auth/middleware.py did not pass audience to verifier.

Change:
- Added strict audience check.
- Added tests for wrong aud, missing aud and valid aud.

Risk:
Could reject misconfigured clients; staging validation required.

Rollback:
Revert middleware change if unexpected 401 spike occurs.

Validation:
- Unit tests pass.
- Staging tested with IdP client.
- Logs monitored for 401 reason codes.

Critères d’acceptation

• La correction ne baisse pas le niveau de sécurité ailleurs.
• Les tests prouvent le comportement sécurisé.
• Les logs sont utiles sans fuite.
• La migration est compatible clients.
• Rollback défini.

Types de tests crypto

Exemples de tests négatifs :
- token expiré rejeté
- certificat non approuvé rejeté
- mauvaise audience rejetée
- nonce dupliqué détecté en test
- HMAC invalide rejeté
- secret factice détecté par scanner pré-commit

ACME : automation, mais pas abandon

ACME automatise l’émission et le renouvellement. Il faut cependant surveiller DNS challenge, HTTP challenge, quotas, permissions, reload Nginx, propagation et échec silencieux.

• Tester renouvellement dry-run.
• Alerter si le certificat installé ne change pas après renouvellement.
• Vérifier reload du reverse proxy.
• Limiter permissions DNS API utilisées pour DNS-01.
• Documenter fallback manuel d’urgence.

# Exemple opérationnel, à adapter
certbot renew --dry-run

# Validation post-renew
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null  | openssl x509 -noout -dates -issuer -subject

mTLS à grande échelle

mTLS fonctionne bien quand l’identité de service est claire. Il échoue quand les certificats clients sont copiés, non renouvelés, non révoqués ou partagés entre environnements.

Service A certificate
  ↓
Gateway verifies client CA
  ↓
Extract service identity
  ↓
Policy:
  service A can call /payments/read
  service A cannot call /payments/admin

Alertes utiles

• Expiration J-60/J-30/J-14/J-7/J-1.
• Certificat servi différent du certificat attendu.
• Issuer inattendu.
• SAN manquant pour endpoint connu.
• Chaîne incomplète.
• Échec renouvellement ACME.
• Spike TLS handshake failures.
• OCSP stapling absent si requis.

Runbook incident expiration

1. Identifier le certificat expiré et les endpoints impactés.
2. Identifier owner et méthode de renouvellement.
3. Émettre certificat de remplacement.
4. Installer fullchain + key via mécanisme sécurisé.
5. Reload/restart service de manière contrôlée.
6. Valider avec SNI et clients critiques.
7. Surveiller erreurs 4xx/5xx/handshake.
8. Rédiger postmortem : pourquoi l’alerte n’a pas fonctionné ?

Incident note:
- Asset:
- Certificate serial:
- Expired at:
- Customer impact:
- Root cause:
- Immediate fix:
- Permanent fix:
- Monitoring added:
- Owner:

Ce que l’IA peut automatiser sans risque excessif

• Comparer inventaire et certificats réellement servis.
• Rédiger tickets par owner.
• Prioriser selon exposition et criticité.
• Résumer incidents d’expiration.
• Suggérer tests de validation.
• Générer runbooks spécifiques par stack.

Inventory diff
  ↓
AI triage
  ↓
Ticket per owner
  ↓
Human approval
  ↓
Automation renews
  ↓
Synthetic tests
  ↓
Close with evidence

Un finding doit être actionnable

ID: CRYPTO-003
Title: JWT audience not enforced
Severity: High
Asset: orders-api
Evidence:
- auth/middleware.py verifies signature but no audience parameter
- tests do not include wrong-audience token
Impact:
- Token issued for another API may be accepted
Recommendation:
- Enforce aud == api://orders
- Add negative tests
Validation:
- Wrong aud rejected with 401
Owner: Backend Team
Due date: 30 days
Residual risk: Low after fix and monitoring

Scoring crypto contextualisé

Le score doit combiner sensibilité de la donnée, exposition, exploitabilité, probabilité d’erreur, facilité de correction et conformité.

Severity = technical weakness
         + exposure
         + asset criticality
         + data sensitivity
         + exploitability
         + compensating controls
         + fix urgency

Pack de preuves sans fuite

• Captures ou extraits masqués.
• Outputs openssl sans clé privée.
• Fragments de configuration sans secrets.
• Chemins de fichiers et numéros de lignes.
• Logs minimisés sans token complet.
• Hashes ou identifiants redacted.
• Résultats de tests négatifs.

Redaction examples:
Authorization: Bearer eyJhbGciOi...<redacted>
AWS_SECRET_ACCESS_KEY=<redacted>
Private key block: NEVER INCLUDE
Certificate public metadata: OK

Traduire pour le management

Le management n’a pas besoin de connaître chaque extension X.509. Il doit comprendre l’impact, les priorités, les ressources nécessaires, le risque de ne rien faire et les délais.

Technique
  ↓
Risque métier
  ↓
Probabilité
  ↓
Impact
  ↓
Coût de correction
  ↓
Décision

Plan 30/60/90 jours

Metrics de maturité

• Pourcentage de certificats avec owner.
• Certificats expirant < 30 jours.
• Secrets statiques vs OIDC/short-lived.
• Services avec tests JWT négatifs.
• Pourcentage de clés avec rotation documentée.
• Findings crypto récurrents par équipe.

Références à intégrer dans le guide

• OWASP ASVS : contrôles applicatifs.
• OWASP Cheat Sheets : TLS, JWT, password storage, secrets management.
• NIST : recommandations cryptographiques et PQC.
• CIS Benchmarks : configurations systèmes/cloud.
• Cloud provider docs : KMS, secrets manager, IAM.
• Mozilla TLS guidelines : profils TLS côté serveur.
• OpenID Foundation : OIDC specs.

Questions d’entretien

1. Comment auditeriez-vous JWT dans une API microservices ?
2. Que mettez-vous dans un rapport crypto pour un RSSI ?
3. Comment prioriser secrets exposés vs certificat expirant ?
4. Pourquoi un rapport doit-il inclure des tests de validation ?
5. Comment éviter qu’un rapport de sécurité fuite des secrets ?