Principe du C2PA et des signatures

Le Content Authenticity Initiative (C2PA) crée un manifeste contenant deux signatures distinctes. La première, dite claim, décrit le contenu (ex. : « photo prise à tel lieu, à telle heure »). La seconde provient d’une Time Stamp Authority (TSA) via le protocole RFC 3161 ; elle atteste que le hachage du claim existait avant le moment indiqué. La confiance repose sur le fait que la TSA ne falsifie pas son horodatage.

Mécanisme d’exclusion et exploitation

Le standard autorise des exclusions : des plages d’octets exclues du calcul du hachage. Cette fonctionnalité, prévue pour gérer des contraintes de format (par ex. les CRC32 des chunks PNG), est décrite dans la spécification officielle. L’auteur du billet exploite ce mécanisme en définissant une exclusion couvrant l’intégralité du fichier, soit 3 995 383 octets. Le manifeste extrait avec c2patool -d montre clairement l’instruction :

{
  "c2pa.hash.data": {
    "exclusions": [{"start":0,"length":3995383}],
    "name":"jumbf manifest",
    "alg":"sha256",
    "hash":"47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=",
    "pad":[]
  }
}

Le hachage indiqué, 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=, correspond au résultat de openssl sha256 -binary /dev/null | base64, c’est‑à‑dire le hachage d’une chaîne vide. Ainsi, la signature porte sur rien, mais la TSA valide toujours le timestamp, car elle signe la signature du claim, qui elle‑même signe le hachage vide. Après coup, l’image peut être modifiée (photoshop du ticket de loterie) sans invalider aucune des deux signatures.

Analyse des risques et limites

Cette technique montre que la confiance accordée aux timestamps C2PA peut être détournée lorsque les exclusions sont trop permissives. Un attaquant peut falsifier le contenu d’une image tout en conservant une preuve temporelle apparente. Le problème se généralise : tant que les vérificateurs ne contrôlent pas la taille ou la nature des exclusions, ils ne peuvent pas distinguer une exclusion légitime (ex. : CRC32) d’une exclusion malveillante couvrant la majeure partie du fichier. Le risque est accentué pour les formats où les métadonnées sont volumineuses, car la surface d’exclusion augmente.

Propositions de mitigation

Une solution immédiate consiste à rejeter les manifests où la plage d’exclusion couvre plus d’un petit pourcentage du fichier, par exemple 1 % ; cela détecterait les cas d’exclusion totale. À plus long terme, la spécification devrait lister explicitement, par format, les sections autorisées à être exclues et imposer aux implémentations de vérifier ces limites. Les implémentations de TSA pourraient également inclure un hachage du fichier complet en plus du claim, afin de détecter les écarts lorsqu’une exclusion dépasse les bornes attendues. Enfin, les outils de vérification devraient alerter l’utilisateur lorsqu’une exclusion dépasse la taille maximale définie, même si elle reste techniquement conforme au schéma.