Confiance cryptographique · PQC & Sceau
La confiance
se construit.
Et se vérifie.
Maîtriser les clés. Donner une portée précise aux autorisations. Préparer les mécanismes post-quantiques : la confiance devient une architecture que vous pouvez examiner.
Architecture en préparation · contrôles illustratifs
01 / Le Sceau RookGuard
Une autorisation précise.
Des conditions visibles.
Un ordre doit correspondre à ce qui a été autorisé. Changez une condition pour voir comment le modèle refuse une demande devenue inéligible.
Le mandat se vérifie avant l’action.
La signature, le périmètre et le droit d’agir restent des contrôles distincts.
En production, l’identité, la signature, les droits et le mandat devront être vérifiés par le service d’autorisation. Cette illustration n’effectue pas de vérification cryptographique.
Modèle logique illustratif. Aucune signature post-quantique n’est calculée et aucune action sur le parc n’est exécutée.
02 / Préparer le post-quantique
Deux fonctions.
Une confiance à organiser.
Établir un secret partagé et vérifier une signature répondent à deux besoins différents. Leur migration doit être pensée avec les protocoles et la garde des clés.
Établir un secret partagé.
ML-KEM est un mécanisme standardisé pour établir un secret partagé. Ce secret peut ensuite servir à protéger les échanges avec des mécanismes symétriques adaptés.
Vérifier l’origine et l’intégrité.
ML-DSA est un standard de signature numérique. Il permet de signer des données et de vérifier leur signature. Le droit d’exécuter une opération reste un contrôle supplémentaire.
03 / L’évolution sous contrôle
Faire évoluer la cryptographie.
Préserver le service.
Une migration ne se résume pas à choisir un algorithme. Elle doit rester compatible avec vos usages et vos moyens de reprise.
Savoir où la confiance est utilisée.
Identifier les échanges, les signatures, les certificats, les responsables des clés et la durée de confidentialité attendue. La priorité dépend des usages réels.
Une délégation délimitée.
Associer une demande d’Arthur à une intention, un périmètre et une durée que l’on peut examiner avant l’exécution.
Des clés sous responsabilité.
Rendre lisibles leur rôle, leur garde, leur rotation et les moyens nécessaires à leur remplacement.
Une évolution préparée.
Relier les exercices de migration aux contraintes du service et aux moyens de reprise indépendants de Phénix.
La maîtrise, en pratique
Souveraineté.
Interopérabilité.
Vérifiabilité.
Développer en interne signifie-t-il inventer un algorithme ?
Le projet consiste à maîtriser l’intégration, la politique de clés, l’orchestration et l’exploitation en s’appuyant sur des standards publics et des implémentations évaluées. La souveraineté ne dispense pas de validation cryptographique indépendante.
Le Sceau remplace-t-il le mandat d’Arthur ?
Le mandat définit les droits et les limites. Le Sceau proposé doit lier une autorisation à une demande précise. La signature vérifie un contenu et une origine ; elle ne donne pas à elle seule le droit d’agir.
La plateforme est-elle déjà protégée de bout en bout par le PQC ?
Cette page présente une architecture en préparation. L’inventaire, le choix des protocoles, l’intégration des mécanismes, les performances, la garde des clés et la reprise restent à qualifier avant toute annonce de couverture en production.
Une confiance qui reste sous votre maîtrise
Préparons les mécanismes
dont dépend votre défense.
Échanges, clés, signatures et autorisations : partons de vos usages pour construire un parcours de migration vérifiable.