Classification du document : Spécification technique publique
Périmètre : Architecture cryptographique de la couche de transport
Politique de révision : Mise à jour avec l'évolution des normes cryptographiques
Document formel de sécurité
Architecture de transport segmenté
post-quantique
Vue d'ensemble de l'architecture
Fig. 1 — Enclave de transport post-quantique segmentée. Compatibilité classique en périphérie ; application stricte PQ uniquement à l'intérieur de la frontière.
1.Terminologie et langage normatif
Les mots-clés MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT et MAY dans ce document sont à interpréter comme décrit dans la RFC 2119.
Sections normatives
Exigences architecturales contraignantes
Sections informatives
Justification de conception et commentaires opérationnels
2.Classification architecturale
3.Exigences normatives
3.1Protocole de transport
3.1.1Bord public
- ▸MUST prendre en charge uniquement TLS 1.3
- ▸MUST NOT prendre en charge TLS 1.2 ou antérieur
- ▸MUST NOT activer les suites de chiffrement legacy
- ▸MAY prendre en charge les mécanismes classiques d'échange de clés pour compatibilité
Justification : les limites de l'écosystème navigateur actuel excluent les points de terminaison externes PQ uniquement.
3.1.2Segment interne post-quantique
- ▸MUST opérer exclusivement en TLS 1.3
- ▸MUST imposer ML-KEM (mlkem768) comme seul groupe d'échange de clés autorisé
- ▸MUST NOT autoriser X25519, P-256 ou tout groupe classique
- ▸MUST exiger la vérification de signature basée sur ML-DSA
- ▸MUST terminer le handshake en cas de non-correspondance de groupe
- ▸MUST terminer le handshake en cas de non-correspondance de signature
- ▸MUST terminer le handshake en cas de tentative de déclassement de protocole
3.2Résistance au déclassement
À l'intérieur de l'enclave PQ :
- ▸Le repli classique d'échange de clés MUST NOT exister
- ▸La négociation de suite de chiffrement MUST NOT inclure d'alternatives classiques
- ▸La négociation de version de protocole MUST rejeter toute version autre que TLS 1.3
- ▸L'échec du handshake MUST être enregistré et traité comme événement de sécurité
3.3Frontière cryptographique
La frontière cryptographique SHALL est définie entre Edge (nginx) et PQ Gate. Tout transport au-delà de cette frontière MUST respecter la politique d'application PQ uniquement.
4.Modèle de menaces (formalisé)
Capacités
- •Interception passive
- •Archivage du trafic
- •Tentative future de déchiffrement quantique
Objectif d'atténuation
Le transport interne MUST être protégé avec ML-KEM pour assurer le secret direct résistant au quantique.
Capacités
- •Interférence de négociation TLS
- •Manipulation de chiffrement
- •Substitution de groupe
Objectif d'atténuation
Les tentatives de déclassement MUST entraîner la terminaison du handshake.
Capacités
- •Écoute passive
- •Accès partiel au réseau
Objectif d'atténuation
Tout trafic inter-composants au-delà de la frontière MUST rester chiffré sous transport PQ uniquement.
5.Section informative — Justification de conception
5.1Pourquoi la segmentation au lieu du PQ complet
En 2026, les navigateurs grand public ne prennent pas en charge ML-KEM, et les composants de l'écosystème (bases de données, caches, mailles de services) n'ont pas de TLS natif PQ. Un point de terminaison externe entièrement PQ entraînerait une perte totale de compatibilité.
Application opérationnelle PQ
Compatibilité ascendante
Évaluation réelle des performances
Transition cryptographique contrôlée
6.Métriques de performance (observées)
Les valeurs représentent le comportement mesuré dans le déploiement actuel ; mises à jour périodiquement.
6.1Surcharge du handshake
~8–15 %
Augmentation de latence vs X25519
~2–4×
Augmentation de la taille des certificats (ML-DSA vs ECDSA)
Aucune observée
Dégradation du service sous charge
6.2Impact sur le débit
- ▸Performances de transfert en masse non affectées (AES-GCM symétrique inchangé)
- ▸Surcharge limitée à la phase de handshake
- ▸La surcharge du transport PQ est en amont et amortie sur les connexions persistantes
6.3Comportement en cas d'échec
- ▸Rejet explicite du handshake en cas de tentative de groupe classique
- ▸Échec explicite en cas de non-correspondance d'algorithme de signature
- ▸Aucun repli silencieux observé
7.Annexe de configuration cryptographique
7.1Configuration du segment PQ interne
Activé
Désactivé
7.2Résumé de la configuration de bord
Activé
Désactivé
8.Stratégie de migration (formalisée)
Phase 1ACTUELLE
Bord public hybride + enclave PQ interne stricte
État opérationnel actuel.
Phase 2
Support externe hybride
Lorsque les navigateurs implémenteront le KEM hybride :
Le bord externe SHOULD activer le KEM hybride.
L'application PQ interne SHALL rester stricte.
Phase 3
Point de terminaison optionnel PQ uniquement
Lorsque l'écosystème navigateur se stabilisera :
Un point de terminaison externe PQ uniquement MAY être introduit.
Le point de terminaison de compatibilité MAY rester temporairement.
Phase 4
Adoption PQ étendue
Lorsque pris en charge par l'écosystème :
Transport PQ service à service.
Connexions base de données à capacité PQ.
Maillage de services conscient du PQ.
9.Principes de gouvernance de la sécurité
Aucune affirmation exagérée d'immunité quantique
Aucun mécanisme de repli silencieux
Aucune exception hybride non documentée
Politique de déclassement explicite
Définition explicite de la frontière de confiance
Application cryptographique mesurable
10.Déclaration de positionnement architectural
Ce système ne prétend pas à une exposition internet post-quantique complète.
Il opère une enclave de transport post-quantique appliquée en production et résistante au déclassement au sein d'un écosystème externe contraint par la compatibilité.
L'architecture reflète une stratégie délibérée de transition cryptographique plutôt qu'un alignement marketing.
Historique des versions
Télécharger
Même contenu que cette page, au format PDF.
Le PDF est disponible en anglais uniquement.