Un paquet de preuves est un ensemble de fichiers de données, un manifeste qui liste l’empreinte SHA-256 de chaque fichier, et une signature Ed25519 portant sur ce manifeste. Cette page contrôle les trois éléments dans votre navigateur. Rien n’est envoyé.
Déposez le paquet entier dans la zone : manifest.json, manifest.sig et les fichiers de données. Ou déposez un seul fichier pour obtenir son SHA-256. Votre navigateur fait le calcul avec WebCrypto. La prise en charge d’Ed25519 par WebCrypto diffère selon les navigateurs et leurs versions ; si le contrôle signale qu’Ed25519 est absent, utilisez les étapes OpenSSL plus bas.
Téléchargez les quatre fichiers, puis déposez-les dans la zone ci-dessus. L’exemple est un cas de stockage par batteries (BESS) : un seul actif illustratif, SAMPLE-BESS-CL-001. Ce n’est pas une centrale réelle, et ses valeurs ne sont pas des mesures. Un paquet signé spécifique au solaire est en attente ; cet exemple ne montre donc que le format.
manifest.json ↓ manifest.sig ↓ telemetry-extract.csv ↓ asset-summary.json ↓
Aucun contrôle n’a encore été effectué. Le résultat apparaît ici, fichier par fichier, dès que vous choisissez ou déposez un paquet.
Le contrôle répond à deux questions. Le manifeste a-t-il été signé par la clé publiée et est-il resté inchangé ? Chaque fichier correspond-il au SHA-256 que liste le manifeste ? Lisez les deux réponses ensemble. Les encadrés ci-dessous montrent la formulation utilisée par le contrôle. Ce sont des exemples, et non les résultats d’un contrôle réel.
correspond au manifeste
correspond au manifeste
Chaque fichier est exactement celui que liste le manifeste, et le manifeste est exactement celui que le détenteur de la clé a signé. Rien n’a été ajouté, supprimé ni modifié après signature.
Soit le manifeste a été modifié après sa signature, soit il a été signé avec une autre clé. Considérez le paquet comme non vérifié, même si toutes les lignes de fichiers correspondent, car le manifeste lui-même n’est pas fiable.
ne correspond PAS — le fichier a été modifié
Un octet modifié dans un fichier de données change son empreinte SHA-256, de sorte que ce fichier échoue. La signature peut rester valide, car le manifeste lui-même n’a pas été touché. Lisez la ligne ✗, et pas seulement la bannière. Si quelqu’un modifie aussi le manifeste pour que la ligne corresponde, la signature devient INVALIDE.
Le format utilise JSON, SHA-256 et Ed25519. Il ne nécessite ni blockchain ni visionneuse propriétaire. Chacun peut l’implémenter, et chacun peut vérifier un paquet sans cette page.
| spec | LTB-Evidence-Manifest/0.1 |
| files[] | chemin, SHA-256 et taille en octets de chaque fichier du paquet |
| asset | l’actif que couvrent les preuves. L’exemple utilise l’identifiant d’un stockage par batteries (BESS), SAMPLE-BESS-CL-001 |
| engine / seed | lorsqu’un modèle a produit une valeur : la version du modèle et la graine aléatoire, afin que la valeur puisse être reproduite |
| key_id | la clé publiée utilisée par le signataire (ltb-2026-10) |
| created | le moment où le signataire a produit le paquet. C’est le signataire qui écrit cette date, et elle n’est pas encore horodatée de manière indépendante |
| manifest.sig | signature Ed25519 détachée portant sur les octets exacts de manifest.json, stockée en texte base64 |
Vous n’avez pas besoin de cette page. Il vous faut OpenSSL 3.x et la clé publique publiée. Exécutez ces trois étapes dans le dossier qui contient le paquet :
Le résultat est « Signature Verified Successfully » ou « Signature Verification Failure ». La deuxième étape écrit la clé publiée au format PEM. La ligne base64 est l’encodage standard SubjectPublicKeyInfo de la même clé de 32 octets : un en-tête Ed25519 fixe de 12 octets, suivi de la clé brute. La clé elle-même ne change pas.
Clé publique publiée (Ed25519, brute, base64), key_id ltb-2026-10 :
Clé publique publiée (Ed25519, brute, base64), key_id ltb-2026-08 :
Deux clés sont publiées. ltb-2026-10 signe les paquets depuis octobre 2026, y compris cet exemple. ltb-2026-08 reste valable pour les paquets signés avant cette date.
Un paquet valide prouve l’intégrité et l’origine. Ces fichiers, tels que listés, ont été signés avec la clé publiée de LIFETIMEBESS et n’ont pas changé depuis la signature. Un paquet valide ne prouve pas :
Vérifiez d’abord les données de supervision d’une installation. Pour un paquet de preuves signé concernant un actif, écrivez-nous.
Obtenir le PV Health Score gratuit Écrire au sujet d’un paquet