Cadre rédactionnel — à valider par un avocat
Cette page décrit le fonctionnement de la chaîne de vérification en pratique. Elle ne constitue pas un avis juridique et ne remplace pas une attestation de conformité formelle revue par un conseil.
Vérification cryptographique, de bout en bout
Chaque pack de preuves est signé au moment où il est produit. Vous pouvez vérifier la signature, le manifeste et l’ancre de la chaîne d’audit hors-ligne — sans avoir à faire confiance à nos serveurs.
Signature — Ed25519
Chaque pack de preuves est signé par le service d’autorité GA Flight via une paire de clés Ed25519. La clé publique est publiée sur /api/authority/public-key ; la clé privée ne quitte jamais l’hôte de signature. La signature couvre l’empreinte du manifeste, pas les fichiers bruts — un seul bit modifié dans n’importe quel fichier du pack invalide la signature, sans nécessiter de re-téléchargement.
Empreinte du manifeste — SHA-256
Le manifeste est un document JSON qui liste chaque fichier du pack avec son empreinte SHA-256, sa taille en octets et son type MIME attendu. La signature couvre le manifeste, et le manifeste couvre chaque fichier individuellement — un seul bit modifié dans un fichier invalide l’empreinte du manifeste et donc la signature.
Ancre de la chaîne d’audit
L’événement de signature est lui-même ajouté à la chaîne d’audit de l’organisation (chaîne d’empreintes sur les lignes `audit_log`). Le lien de la chaîne est exposé sous `chain_hash_prefix` + `prev_hash_prefix` sur la ligne qui enregistre la création du pack. Pour prouver que le pack a été émis à la date affichée, ancrez ces préfixes à un horodatage tiers (par exemple une preuve OpenTimestamps, ou une capture dans votre gestion documentaire).
CLI de vérification hors-ligne
Un script shell POSIX qui reproduit les trois contrôles ci-dessus sans nécessiter de confiance dans nos serveurs. Téléchargez-le depuis /verify/cli/offline-verify.sh, puis exécutez `bash offline-verify.sh chemin/vers/pack.zip`. Ne nécessite que `openssl`, `jq` et `unzip` — aucun Node, aucun Python, aucun binaire GA Flight. Code source sous licence MIT.
Comment les validations sont signées
Chaque validation de formation intégrée à un dossier vérifié porte sa propre signature Ed25519, émise par l'école de l'élève au moyen de la clé de signature propre à cette organisation. La page publique de vérification ci-dessus valide chaque validation individuellement — un tiers n'a jamais besoin de faire confiance à la seule signature de notre plateforme.
Chaque validation comporte le code de l'item de la progression, l'instructeur signataire, la date et une empreinte SHA-256 de la charge utile canonique. La signature Ed25519 lie mathématiquement la signature à ce contenu exact. Modifier les notes invalide la signature ; les révocations sont elles-mêmes signées et ne sont qu'en ajout (append-only).
Vérifier hors-ligne, sans contacter nos serveurs
Le zip du pilot pack téléchargé inclut un script offline-verify.sh. Nécessite openssl (>= 1.1.1) et jq.
unzip pilot-pack.zip -d pack/ cd pack/ chmod +x offline-verify.sh ./offline-verify.sh
Ce que cela ne prouve PAS
La vérification prouve que les octets que vous avez correspondent à ce que nous avons signé, et que nous détenons la clé privée associée à la clé publique publiée. Elle ne prouve pas que les vols, les événements de formation ou les enregistrements de conformité sous-jacents ont été correctement saisis à la source — il s’agit d’une question de contrôles procéduraux hors chaîne.