Hash, signature, attestation et provenance : quelles différences ?

Dans le chapitre précédent, nous avons découvert le besoin de preuve. Ici, nous clarifions les objets rencontrés : hash, attestation, provenance, signature. L’ordre compte : identifions d’abord le contenu, puis l’affirmation, sa nature et enfin ce qui permet de l’authentifier.

1 — Hash : de quel contenu parlons-nous ?

Le hash relie des octets à une empreinte calculée, également appelée digest. Pour notre archive :

SHA256(payment-service-4.7.2.tar.gz)
→ 3a16...9f21

Le calcul est déterministe : les mêmes octets donnent le même digest. Une modification produit normalement une empreinte différente. Les valeurs de ce chapitre sont fictives et abrégées ; un SHA-256 complet contient 64 caractères hexadécimaux.

La comparaison concerne l’identité du contenu, sous les hypothèses de résistance du hash cryptographique. Elle ne dit ni pourquoi les octets diffèrent ni lequel des deux fichiers est légitime. Deux archives contenant les mêmes sources peuvent, par exemple, différer à cause des dates enregistrées ou de la compression.

Le hash identifie le contenu. Il n’identifie pas son histoire.

Son rôle dans notre carte mentale est précis : permettre à une déclaration de désigner le contenu concerné, indépendamment de son nom. L’auteur, le builder et le processus ne se déduisent pas du digest.

2 — Attestation : qu’affirmons-nous à propos de ce contenu ?

Une attestation porte une affirmation structurée sur un sujet. Le digest identifie ce sujet ; l’affirmation indique ce que nous déclarons à son propos.

Exemple conceptuel simplifié, non normatif :

{
  "subject": {
    "name": "payment-service-4.7.2.tar.gz",
    "sha256": "3a16...9f21"
  },
  "claim": {
    "tests": "passed"
  }
}

Le même sujet pourrait recevoir plusieurs affirmations : tests réussis, livraison approuvée, fabrication depuis un commit donné. Identifier l’archive ne suffit donc pas : il faut lire ce qui est affirmé.

Notre exemple ne précise ni la suite de tests ni ses conditions d’exécution. Sa structure facilite la lecture, sans compléter ces informations. Ce n’est pas un Statement in-toto utilisable ; nous distinguerons sa structure réelle au chapitre suivant.

Une attestation répond ainsi à une question différente du hash. Elle donne un contenu à examiner, dont la précision, l’exhaustivité et la véracité restent à évaluer.

3 — Provenance : que savons-nous de la fabrication ?

La provenance est une catégorie d’informations concernant l’origine ou la fabrication d’un artefact. Elle peut décrire les sources, le commit, le builder, les paramètres, les dépendances ou matériaux, le processus et l’environnement.

Comparons deux affirmations sur le même digest :

• « Les tests de livraison ont réussi » décrit une évaluation.
• « Cet artefact a été produit depuis ce commit par ce builder » décrit sa fabrication : c’est une affirmation de provenance.

Une provenance peut être portée par une attestation. Toute attestation n’est pas une provenance.

La provenance se situe donc dans les informations déclarées. Elle n’est pas une enveloppe supplémentaire autour d’une signature. Voici la partie déclarative d’une attestation contenant des informations de fabrication :

Cette vue prépare la structure in-toto : subject désigne l’archive, predicateType indique la nature de l’affirmation et predicate porte les données associées. Le mot « provenance » est ici une étiquette pédagogique : dans le format réel, le type est identifié par une URI. Les données et l’affichage sont simplifiés, sans reproduire un schéma de provenance officiel.

SLSA propose notamment un modèle de provenance, étudié au chapitre 04. La notion de provenance est plus large que ce modèle particulier.

4 — Signature : quelle clé porte l’affirmation ?

Nous savons maintenant ce qui doit être signé : une déclaration précise sur un contenu identifié.

MESSAGE + CLÉ PRIVÉE → SIGNATURE
MESSAGE + SIGNATURE + CLÉ PUBLIQUE → VÉRIFICATION

Sous les hypothèses du mécanisme cryptographique utilisé, une signature permet de vérifier le lien entre le contenu signé et une clé, ainsi que l’intégrité de ce contenu. La clé privée sert à signer ; la clé publique permet le contrôle.

Deux décisions restent distinctes : la signature est-elle valide avec cette clé ? Et pourquoi acceptons-nous cette clé pour cette livraison ? Une clé n’est pas automatiquement une personne, une entreprise ou une autorité légitime. Le modèle de confiance définit son acceptation et son périmètre d’usage.

Attention aussi au périmètre signé : la signature du message protège le message. Si l’archive change mais que le message reste intact, la signature peut rester valide. C’est la comparaison entre l’archive et le digest déclaré qui révèle alors l’écart.

5 — Les quatre mécanismes côte à côte

Mécanisme	Question principale	Ce qu’il relie	Ce qu’il ne garantit pas
Hash	De quel contenu parlons-nous ?	Des octets à une empreinte calculée.	L’origine légitime, l’auteur ou la sécurité du contenu.
Attestation	Qu’est-ce qui est affirmé au sujet de cet objet ?	Un sujet à une affirmation structurée.	Une affirmation vraie, complète ou signée.
Provenance	Comment cet artefact a-t-il été produit ?	Un artefact à ses conditions de fabrication déclarées.	La vérité ou l’exhaustivité du récit.
Signature	Quelle clé porte cette affirmation et l’affirmation a-t-elle été modifiée ?	Le contenu exact signé à une clé, sous les hypothèses cryptographiques retenues.	L’autorisation de la clé ou la vérité de l’affirmation.

Ces mécanismes ne sont pas quatre degrés de certitude. Chacun établit ou décrit une relation différente. Trouver un digest dans un document ne garantit pas que ce document parle de fabrication ; trouver une signature ne dit pas encore si sa clé est acceptée.

6 — Quatre distinctions à garder

• VALID HASH ≠ LEGITIMATE ORIGIN. Un attaquant peut calculer correctement l’empreinte de malicious-payment-service.tar.gz. Accepter la référence reste une décision séparée.
• ATTESTED ≠ TRUE. Mettre une affirmation dans des champs structurés ne la rend pas exacte.
• SIGNED ≠ TRUE. « All tests passed » peut être signé alors que le système a testé le mauvais commit ou une suite insuffisante.
• VALID SIGNATURE ≠ TRUSTED SIGNER. Une signature valide avec une clé inconnue n’autorise pas cette clé à parler au nom du fournisseur.

La cryptographie peut rendre une affirmation vérifiable. Elle ne transforme pas une affirmation en vérité.

Ces limites n’annulent pas l’intérêt des contrôles. Elles permettent d’en exprimer la portée sans confondre intégrité, attribution, autorisation et exactitude du récit.

7 — La carte des relations et des contrôles

L’artefact donne le digest qui identifie le sujet. L’attestation associe ce sujet à une affirmation ; dans notre exemple, cette affirmation contient la provenance. La signature couvre la représentation signée de cette déclaration. Le destinataire vérifie ensuite ces relations selon ses références et sa politique de confiance.

Tous les éléments du document sont déjà présents avant la signature. Le mouvement guide la lecture des relations ; il ne représente pas une fabrication progressive du document. Les encodages et l’enveloppe de signature sont omis. La provenance apparaît dans la déclaration, jamais comme une étape ajoutée après sa signature.

Chaque contrôle peut donner un résultat différent. Conservons les quatre cas de comparaison, en supposant une référence de digest inchangée et une seule clé autorisée :

Cas	Digest de l’archive	Signature du message	Clé autorisée
Dossier de référence	Correspond	Valide	Oui
Archive seule modifiée	Diffère	Toujours valide	Oui
Résultat de tests modifié dans le message, sans nouvelle signature	Correspond	Invalide	Oui
Même message resigné avec une autre clé	Correspond	Valide avec cette autre clé	Non

Ce tableau ne prononce pas un verdict de sécurité. Il indique où la relation change. La provenance ouvre d’autres comparaisons : le commit déclaré est-il celui attendu ? Le builder est-il accepté ? Ces contrôles ne rejouent pas les événements enregistrés.

8 — Et Continuum Attest ?

Continuum Attest 0.1.0 combine plusieurs de ces mécanismes pour enregistrer des éléments liés à l’exécution d’un pipeline et permettre leur vérification dans des receipts. La signature est activée explicitement ; le recalcul des empreintes depuis l’espace de travail est un contrôle distinct. Ces possibilités ne garantissent ni la vérité de toutes les déclarations ni la sécurité du logiciel.

9 — La carte à retenir, puis l’objet à ouvrir

• Hash : identifie un contenu.
• Attestation : porte une affirmation structurée sur un sujet.
• Provenance : décrit les informations relatives à sa fabrication ou à son origine.
• Signature : permet de contrôler le contenu signé et son lien à une clé ; accepter cette clé dépend du modèle de confiance.

L’attestation a besoin d’une structure pour désigner son sujet, indiquer la nature de l’affirmation et porter les données associées. Dans le Statement in-toto, nous retrouverons subject, predicateType et predicate.

C’est précisément ce que nous allons ouvrir dans le chapitre suivant : après la découverte du problème au chapitre 01 et la clarification des concepts ici, nous examinerons une attestation réelle. Le chapitre 04 approfondira ensuite SLSA Provenance.

03 — Anatomie d’une attestation in-toto