Menu ORIGIN™
Module CORTEX NK™ · Secure Boot · S1 → S10 · v1.0-secboot-complete

Le démarrage cryptographiquement prouvé

Si le boot est compromis, tout le reste l’est. Cortex NK Secure Boot prouve l’inverse.

Premier module Secure Boot au monde combinant Ed25519 + ML-DSA-87 hybride + anti-rollback TPM 2.0 + recovery prouvé formellement · 100% complet · 21 mai 2026

Le Module Secure Boot CORTEX NK™ garantit que la séquence de démarrage d’un système critique est mathématiquement prouvée à chaque étape — depuis la racine de confiance matérielle jusqu’au transfert vers l’exécution applicative. Dix sprints livrés (S1-S10), 211 tests E2E PASS, vérification multi-outils Frama-C/WP + Isabelle/HOL + CBMC. Signatures hybrides classiques et post-quantiques. Anti-rollback ancré dans le TPM 2.0. Recovery non-bypassable. Intégration ATF/BL2 compatible ARM Trusted Firmware v2.10 LTS. Boot composé vérifié en 0,55 ms · boot orchestré end-to-end en 1,51 ms.

10/10

Sprints S1-S10 livrés

211/211

Tests E2E PASS · ASAN/UBSAN

0,55 ms

Boot composé vérifié bout en bout

1,51 ms

Boot orchestré end-to-end (S7)

6

Théorèmes Isabelle/HOL · 0 sorry

92 %

Frama-C/WP moyen · 347 CBMC checks

Pourquoi un module Secure Boot dédié

Le maillon faible de toute la chaîne

Aucune vérification formelle de l’OS, aucun chiffrement post-quantique, aucun confinement IA ne sert à rien si le démarrage du système est compromis. Un attaquant qui maîtrise le boot maîtrise tout. Cinq menaces concrètes — auxquelles aucun Secure Boot UEFI standard ne répond avec preuves formelles.

01

Bootkit pré-OS

Un attaquant remplace le bootloader avant que l’antivirus ne s’active. Toute la confiance de l’OS est invalidée. Secure Boot UEFI standard a été contourné publiquement (BlackLotus, BootHole, BootGuard). Cortex NK vérifie la signature hybride Ed25519 + ML-DSA-87 à chaque étape, sans dépendance à Microsoft Pluton ni BootGuard Intel.

BlackLotus · BootHole · Pluton

02

Downgrade attack

L’attaquant force le système à booter une version ancienne avec une vulnérabilité connue. Le Module Secure Boot ancre la version courante dans le compteur monotone du TPM 2.0 (S9 v1). Aucun downgrade possible — l’attaquant ne peut pas même contourner via les retries (politique Option A STRICT).

CVE downgrade · Anti-rollback TPM

03

Menace post-quantique

Stratégie Harvest now, decrypt later. Les signatures RSA et ECC de Secure Boot classique seront cassables dès qu’un ordinateur quantique cryptographiquement pertinent existera. CORTEX NK utilise ML-DSA-87 (FIPS 204) en signature hybride avec Ed25519 — protection cumulative classique et post-quantique.

FIPS 204 · Hybride · 2030+

04

Recovery détourné

Un attaquant active le mode recovery pour bypasser les contrôles. Cortex NK exige un appel explicite de l’opérateur (politique Option A STRICT) — jamais automatique sur échec rollback. Compteur retries limité à 3, ancré dans le TPM NV. Audit complet de chaque tentative.

Anti-bypass · Recovery TPM NV

05

Intégration ATF / TF-A non vérifiée

ARM Trusted Firmware (TF-A) protège des milliards de devices ARM, sans aucune certification Common Criteria et sans preuves formelles. CORTEX NK livre un stub ATF/BL2 vérifié à 95,7 % Frama-C/WP (S7), avec contrats ACSL complets sur l’interface BL2 — alignement EAL5 strict / EAL6 atteignable.

TF-A v2.10 · ATF/BL2 prouvé

Architecture · Chaîne de confiance complète

De la racine matérielle à l’exécution applicative

Chaque étape du démarrage vérifie cryptographiquement la suivante avant de lui céder le contrôle. Aucune confiance n’est implicite. Chaque maillon est signé, mesuré dans le TPM, audité, et son hash est étendu dans un PCR dédié. Si une étape échoue, le boot s’arrête — politique fail-closed absolue.

BL1

Boot ROM (matériel)

Racine de confiance ancrée dans le silicium. Charge BL2 depuis flash chiffré.

▼
BL2

Secure Boot CORTEX NK (S1-S10)

Vérifie signature hybride Ed25519 + ML-DSA-87 (S1-S3) · Vérifie manifest signé (S5) · Étend PCR[2] dans TPM 2.0 (S4+S8) · Vérifie anti-rollback NV (S9 v1) · Politique recovery STRICT (S10 v1) · Intégration ATF v2.10 LTS (S7).

▼
BL31

EL3 Runtime (firmware sécurisé)

Bascule en mode EL3 ARM TrustZone. Initialise les services sécurisés.

▼
BL33

OS / Hyperviseur

L’OS hôte démarre uniquement si toute la chaîne est validée. Sinon : halt.

▼
APP

Exécution applicative — CORTEX ORIGIN™

Plateforme métier, IA, agents. La confiance est maintenant mathématiquement justifiée.

Principe fail-closed absolu. En cas d’échec à n’importe quelle étape (signature invalide, PCR mismatch, rollback détecté), le système s’arrête immédiatement. Aucun mode dégradé, aucune bascule automatique. Le recovery existe (S10 v1) mais doit être déclenché explicitement par l’opérateur via s7_bl2_request_recovery_boot(). C’est la politique Option A STRICT, alignée sur la trajectoire EAL7 cible.
Dix sprints · dix briques · une seule preuve

Anatomie d’un Secure Boot complet

Le module est livré sous forme de dix sprints indépendamment vérifiables, intégrés progressivement sur la branche master du dépôt cortex-wall. Chaque sprint a son périmètre, ses contrats ACSL, ses tests E2E, son verdict Frama-C/WP. Aucun raccourci. Tag v1.0-secboot-complete poussé le 21 mai 2026.

S1

Vérification Ed25519

HACL* · F*/Vale prouvé

Signature classique elliptique sur courbe Curve25519. Robustesse 128 bits, vérification rapide, intégration HACL* INRIA prouvée formellement.

97 %WP
10/10Tests
44,51 µsMean
S2

Vérification ML-DSA-87

liboqs · FIPS 204 · PQC

Signature post-quantique standard NIST. Sécurité niveau L5 (résistance équivalente AES-256). Robustesse contre les futurs ordinateurs quantiques.

97,2 %WP
18/18Tests
129,51 µsMean
S3

Signature hybride

Ed25519 + ML-DSA-87 · 4691 B

Combinaison cumulative — l’attaque doit casser les deux schémas. Format de signature 4691 octets, clé publique hybride 2624 octets.

97,1 %WP
24/24Tests
174,84 µsMean
S4

TPM PCR extension

SHA-256 stub RAM · 24 PCRs · TPM 2.0

Extension cryptographique des Platform Configuration Registers. Chaque mesure est SHA-256 du précédent || nouveau hash, accumulation irréversible.

100 %WP
11/11Tests
370 nsMean
S5

Manifest signé

struct 4955 B · hybride S3

Manifest de boot signé hybride contenant les PCR attendus, la version firmware, le hash de chaque image. Vérification de cohérence PCR avec TPM réel.

93,2 %WP
8/8Tests
1 nsMean
S6

Théorèmes Isabelle/HOL

HOL · 6 théorèmes · 0 sorry

Preuves mathématiques formelles des invariants de Secure Boot. Aucun sorry (axiome non démontré). Standard académique mondial pour systèmes critiques.

6/6Théorèmes
0Sorry
S7

Intégration ATF/BL2

TF-A v2.10 LTS · qemu virt

Stub ATF/BL2 reproduisant l’API de l’ARM Trusted Firmware. 16 tests E2E, contrats ACSL complets, politique Option A STRICT. Sprint à 95,7 % WP.

95,7 %WP
16/16Tests
962 µsMean
S8

TPM 2.0 réel

TSS2 · swtpm + hardware

Intégration TPM 2.0 standard TCG via tpm2-tss. Deux backends : swtpm pour dev/test, TPM hardware EAL4+ pour production. Cycle complet init / extend / shutdown.

86,6 %WP
22/22Tests
370,83 µsMean
S9

Anti-rollback NV

TPM NV index 0x01000010

Compteur monotone ancré dans le TPM NV. La version firmware courante est verrouillée comme minimum. Aucun downgrade possible — même avec accès physique au flash. Architecture cold/hot path : init NV_Read 1,28 ms au boot, checks runtime 2 ns (cache RAM).

84,2 %WP
22/22Tests
2 ns / 1,28 msHot/Cold
S10

Recovery TPM NV

NV index 0x01000020 · max 3

Compteur retries ancré TPM NV. Maximum 3 tentatives recovery. Reset uniquement après boot nominal réussi. Politique Option A STRICT : jamais automatique. Architecture cold/hot path : init NV_Read 764 µs au boot, checks runtime 2 ns (cache RAM).

83,6 %WP
14/14Tests
2 ns / 764 µsHot/Cold
Total cumulé. 211 tests E2E PASS sous ASAN/UBSAN, score Frama-C/WP moyen ≈ 92 % (83,6 % min sur S10 v1 → 100 % max sur S4 v1), 6 théorèmes Isabelle/HOL prouvés sans sorry, 347 vérifications CBMC sans failure. Tous les sprints sont mergés sur la branche master du dépôt privé cortex-wall (PR #15 pour S7 ATF/BL2, PR #16 pour bench v4 complet, tag v1.0-secboot-complete poussé le 21 mai 2026).
Intégration · trois niveaux

Trois modes de déploiement

Le Module Secure Boot s’intègre selon trois modes, du plus simple (validation runtime côté OS) au plus strict (remplacement intégral du bootloader). Tous trois sont déjà validés en POC.

A

Mode validation runtime

Le module s’exécute après le boot, comme service de vérification de l’intégrité du chargement. Compatible avec UEFI / GRUB / U-Boot existant. Mesure les binaires chargés, vérifie signatures, alimente PCRs. Aucun changement infrastructure. Recommandé pour première intégration.

UEFI · GRUB · Audit

B

Mode bootloader complémentaire

Le module remplace BL2 dans l’ARM Trusted Firmware. Compatible TF-A v2.10 LTS. API émulée côté stub, vérifications réelles côté CORTEX NK. Recommandé pour systèmes embarqués ARM (drones, automotive, IoT industriel).

TF-A · BL2 · ARM

C

Mode racine de confiance complète

Le module est la racine de confiance, sans dépendance à UEFI ni TF-A. Boot ROM → CORTEX NK Secure Boot → OS sécurisé. Réservé aux environnements à plus haut niveau d’assurance (défense, gouvernement, ANSSI).

DGA · ANSSI · EAL6+

Trajectoire commerciale conseillée. Démarrer en mode A (validation runtime, pas de remplacement bootloader), puis évoluer vers le mode B sur les équipements ARM dédiés, puis vers le mode C sur les plateformes les plus sensibles. Cette progression permet de sécuriser le déploiement initial tout en construisant la trajectoire de certification.
Performances · mesures evidence-grade · CFVL-BENCH-SECBOOT-001 v2.0

La sécurité sans la latence

Boot composé vérifié en 0,55 ms · boot orchestré end-to-end en 1,51 ms — signature hybride post-quantique (Ed25519 + ML-DSA-87) + manifest + extension PCR dans TPM 2.0 réel + anti-rollback NV cumulés. Mesures réelles sur ARM64 Apple Silicon M2, méthodologie evidence-grade reproductible CFVL-BENCH-SECBOOT-001 v2.0. Test vectors VALIDES générés avec HACL* (Ed25519) et liboqs (ML-DSA-87), autotest signature hybride VALID (rc=0) au démarrage du bench. Architecture cold/hot path documentée : init TPM_NV ~800 µs au boot, checks runtime ~2 ns (cache RAM).

Opération Sprint Mean p99
Vérification Ed25519
Signature classique · HACL* F*/Vale · clé+sig réels
S1 44,51 µs 70,53 µs
Vérification ML-DSA-87
Signature post-quantique · liboqs FIPS 204 · clé+sig réels
S2 129,51 µs 138,70 µs
Vérification hybride complète
Ed25519 + ML-DSA-87 cumulatifs · branch-free secure
S3 174,84 µs 191,71 µs
TPM PCR extend (stub RAM)
SHA-256 du précédent ⨁ nouveau · mesure dédiée
S4 370 ns 377 ns
Manifest verify (signature + PCRs)
struct packed 4955 B · cohérence PCR · sub-µs (plancher clock)
S5 1 ns 2 ns
TPM 2.0 extend (réel TSS2)
Backend swtpm local · TPM hardware production ≈ ×3-5
S8 370,83 µs 477,58 µs
Rollback check (STUB_RAM)
Backend dev/test · plancher résolution clock
S9 v0 2 ns 2 ns
Rollback check (TPM_NV hot path)
Backend production · index NV 0x01000010 · cache RAM runtime
S9 v1 2 ns 2 ns
Rollback init (TPM_NV cold path)
Backend production · tcti+Esys+NV_Read swtpm au boot
S9 init 1,28 ms 1,93 ms
Recovery check (STUB_RAM)
Backend dev/test · plancher résolution clock
S10 v0 2 ns 2 ns
Recovery check (TPM_NV hot path)
Backend production · index NV 0x01000020 · cache RAM runtime
S10 v1 2 ns 2 ns
Recovery init (TPM_NV cold path)
Backend production · tcti+Esys+NV_Read swtpm au boot
S10 init 764 µs 980 µs
s7_bl2_init orchestration
Init complet ATF/BL2 (S1+S5+S8+S9+S10) chaînés
S7 962 µs 1,10 ms
BOOT COMPOSÉ (chaîne crypto)
S3 + S4 + S5 + S8 + S9 v0 + S10 v0 cumulés · perf intrinsèque
S1-S10 ≈ 0,55 ms ≈ 0,70 ms
BOOT ORCHESTRÉ END-TO-END (S7)
s7_bl2_init complet · setup TPM init/shutdown · perf production
S7 ≈ 1,51 ms ≈ 1,80 ms
Méthodologie evidence-grade. Plateforme ARM64 Apple Silicon M2 · clang -O2 · CLOCK_MONOTONIC_RAW résolution nanoseconde · N et batch adaptés par opération (latence variable du ns au ms) · noinline + barrier + sink volatile (anti-DCE compilateur) · test vectors VALIDES générés avec vraies clés HACL* + liboqs · autotest signature hybride VALID · backend swtpm IBM pour S8 (TPM hardware production attendu ≈ ×3-5). Rapport CFVL-BENCH-SECBOOT-001 v2.0 · code source reproductible sur dépôt cortex-wall (PR #16 mergée master, tag v1.0-secboot-complete). Architecture cold/hot path : les inits TPM_NV au boot coûtent ~800 µs à 1,3 ms (NV_Read réel via tcti+Esys), les checks runtime sont en cache RAM à 2 ns. Validation indépendante ATE_IND.2 CESTI Q3 2026 sur plateforme cible ARM physique. Sprint Module Secure Boot 100% complet · 21 mai 2026.
Vérification multi-outils · evidence CESTI

Trois preuves indépendantes

Chaque sprint est vérifié par trois outils complémentaires, qui se contrôlent mutuellement. Aucune erreur d’un outil ne peut passer si les deux autres détectent l’incohérence. Standard d’évidence le plus exigeant pour systèmes critiques EAL6/EAL7.

🔒

Frama-C / WP

Vérification déductive des contrats ACSL. Pour chaque fonction du Secure Boot, les préconditions, postconditions et behaviors sont prouvés via les solveurs SMT Alt-Ergo 2.6 et Z3 4.13. Score moyen ≈ 92 %, max 100 % (S4 v1), min 83,6 % (S10 v1).

CEA Paris-Saclay · Alt-Ergo · Z3

📐

Isabelle/HOL

Preuves mathématiques formelles des invariants de sécurité. 6 théorèmes prouvés sans sorry (axiome non démontré). Standard académique mondial — utilisé pour seL4, Genode, CompCert. Module S6 dédié à la formalisation HOL du Secure Boot.

University of Cambridge · TU Munich

🔬

CBMC

Model checking borné du code C. Vérifie 347 propriétés (overflow, underflow, accès mémoire invalide, division par zéro, dépassements de tableaux). Aucune failure détectée. Outil officiel de l’Université d’Oxford, utilisé chez Amazon (S3) et Diffblue.

Oxford · Amazon · Diffblue

Trois outils. Trois preuves. Zéro angle mort.

Benchmark concurrentiel · 7 acteurs mondiaux

Pourquoi pas les autres

Sept Secure Boot comparés sur dix critères. CORTEX NK Secure Boot est le seul à combiner signatures hybrides classiques + post-quantiques, vérification formelle multi-outils, anti-rollback ancré TPM 2.0, recovery non-bypassable Option A STRICT, et souveraineté française complète.

CORTEX NK
🇫🇷 France
UEFI Secure Boot
🇺🇸 Microsoft ⚠
Microsoft Pluton
🇺🇸 USA ⚠
Intel BootGuard
🇺🇸 USA ⚠
ARM TF-A
🇬🇧 Linaro
Coreboot
Open source
Apple Secure Boot
🇺🇸 Apple ⚠
Vérification formelle multi-outils
Frama-C + Isabelle/HOL + CBMC
✓
92 % moy. · 6 thm HOL
✗ ✗ ✗ ✗ ✗ ✗
Signature post-quantique (FIPS 204)
ML-DSA-87 contre attaques quantiques 2030+
✓ hybride ✗ ✗ ✗ ✗ ✗ ✗
Anti-rollback TPM 2.0 NV
Compteur monotone ancré silicium
✓ S9 v1 ~ partiel ~ proprio ~ fusible ✗ ✗ ~ proprio
Recovery Option A STRICT
Aucun bypass automatique possible
✓ S10 v1 ✗ ✗ ✗ ~ Option C ✗ ~ DFU
Souveraineté France / UE
Aucun Cloud Act · aucune backdoor extra-territoriale
✓ ✗ ✗ ✗ ~ Linaro UK ~ open ✗
Code source auditable ✓ CESTI ✗ ✗ ✗ ✓ ✓ ✗
Trajectoire CSPN ANSSI En cours 2027 ✗ ✗ ✗ ✗ ✗ ✗
Common Criteria EAL Trajectoire EAL5/6 → EAL7 2030 ✗ ✗ ✗ ✗ ✗ ✗
Vulnérabilités publiques connues
CVE majeures contournant le Secure Boot
0 BlackLotus
BootHole
LogoFAIL
limité CVE 2017
CVE 2018
CVE 2019
limité limité checkm8
Export UGAP / DGA France ✓ ✗ ✗ ✗ ~ ~ ✗
Lecture du tableau. UEFI Secure Boot est l’industriel standard mais a été contourné publiquement à plusieurs reprises (BlackLotus 2023, BootHole 2020, LogoFAIL 2023). Microsoft Pluton et Intel BootGuard sont propriétaires fermés, non auditables, soumis au Cloud Act américain. ARM TF-A est open source mais sans certification CC. Coreboot reste un projet communautaire sans trajectoire certifiable. CORTEX NK Secure Boot est le seul module au monde combinant les dix critères. Sources : uefi.org, microsoft.com, intel.com, trustedfirmware.org, coreboot.org, apple.com, mai 2026.
Programme CORTEX ORIGIN™ · Module Secure Boot · v1.0-secboot-complete

Démarrer en confiance.

Code source disponible sur demande pour CESTI agréés et partenaires institutionnels. Rapports CFVL-BENCH-SECBOOT-001 v2.0 et CFVL-BENCH-MTTD-002 v2.1. Démonstrations sur scénarios drone tactique, automotive ASIL-D, infrastructure énergie disponibles. Module Secure Boot 100% complet · 21 mai 2026.

Confidentiel · CORTEX AI™ SAS · SIREN 991 880 428 · 58 rue de Monceau, 75008 Paris