6 min de lecture
Partage en lecture seule : vérifier les preuves et tester le watermark
Une promesse de sécurité doit pouvoir être examinée. Nous publions les outils qui permettent de vérifier les preuves d'une remise de document, de tester l'accès en lecture seule et de mesurer la résistance du watermark. Les résultats comprennent aussi les transformations qui effacent le marquage.
Quatre questions que vous pouvez vérifier
L'original est-il accessible au prestataire ?
La consultation donne accès aux pages de sa copie chiffrée. Le test HTTP contrôle les refus d'accès à l'original, aux clés et aux copies révoquées ou expirées, avec un accès propriétaire comme contrôle positif.
Le fichier a-t-il changé ?
Le vérificateur recalcule l'empreinte SHA-256 du fichier et la compare au manifeste signé lors de la remise. Des octets modifiés ne correspondent plus à cette référence.
Le journal a-t-il été réécrit ?
Les événements sont chaînés par leurs empreintes. Un checkpoint horodaté, conservé hors du serveur avant une compromission, permet de comparer l'état retenu au journal fourni ensuite.
Une capture correspond-elle à une copie remise ?
Le détecteur recherche le motif invisible associé à une copie. Une correspondance renseigne sur ce motif. Elle ne prouve pas quelle personne a diffusé le document.
Un exemple concret : retrouver une modification
Vous remettez une copie d'un PDF à un prestataire. Le manifeste contient l'empreinte de l'original et une signature par passkey. Plus tard, un fichier présenté comme cet original contient une modification. Le vérificateur recalcule son empreinte : la comparaison échoue. Il contrôle également la signature, pour éviter d'accepter un manifeste simplement remplacé avec le fichier.
Si le serveur est compromis, une chaîne de hashes peut être recalculée par l'attaquant. La vérification s'appuie alors aussi sur un checkpoint conservé indépendamment avant l'incident et sur les horodatages validés avec une autorité de confiance choisie indépendamment. Télécharger un nouveau checkpoint après l'incident ne prouve pas l'état antérieur.
Ce que les tests publics exécutent réellement
- Signatures ES256 et réponses d'horodatage RFC 3161 générées et vérifiées, puis tentatives de modification du fichier, du manifeste, des signatures et des tokens.
- Journaux modifiés, réécrits, tronqués, séquences dupliquées et comparaison avec un checkpoint retenu.
- Vraie capture Chrome à 100 %, recadrages, encodages JPEG, redimensionnement, rotation, contraste et effacement du watermark.
- Outil HTTP pour un environnement de test préparé, avec sessions propriétaire et prestataire distinctes. Il rejette aussi les réponses HTML de WAF et les octets de page modifiés.
Les tests cryptographiques utilisent une autorité locale éphémère pour être reproductibles. Elle ne fournit pas une heure indépendante de production ni un horodatage qualifié. Les tests HTTP locaux valident l'outil ; l'audit d'un site déployé doit être exécuté séparément avec ses ressources de test.
Watermark invisible : les résultats, y compris les échecs
Le banc d'essai utilise trois pages synthétiques de 1920 × 1440 pixels, avec un fond blanc, gris ou texturé, et huit motifs de copies candidates. Aucun document personnel n'est publié. Chaque nombre indique les détections correctes dans cet échantillon. Pour les recadrages, le pourcentage désigne la surface retirée.
La rotation de 2° échoue sur les trois pages. Le blanchiment efface le watermark de la page à fond blanc ; celui des deux autres fonds survit. La recréation depuis la source non marquée efface le motif. Elle est testée sans moteur OCR, et ne représente pas un passage OCR mesuré.
Les six contrôles négatifs, pages non marquées et analyses avec une mauvaise clé, n'ont produit aucune correspondance. Cet échantillon ne suffit pas à établir une probabilité de fausse attribution pour tous les documents. Les photos réelles, les perspectives d'une caméra et les attaques par collusion restent hors de cette mesure.
Mesure de référence : . Empreintes des pixels, scores et versions des outils.
Les limites à garder en tête
- Un contenu affiché peut être capturé ou photographié, même si l'original n'est pas téléchargeable.
- L'absence de watermark n'exclut pas l'origine d'une copie. Une correspondance ne prouve pas l'identité de la personne responsable d'une fuite ; les détenteurs de la clé d'audit peuvent aussi générer des motifs.
- Une signature établit l'usage d'une clé. Ces preuves seules ne démontrent pas que cette clé est stockée dans du matériel non exportable ni l'identité physique du signataire.
- Le journal atteste la continuité des maillons fournis. Il ne prouve pas tous les événements possibles, ceux jamais enregistrés, ni un historique complet en dehors de la plage exportée. La partie après le dernier checkpoint horodaté n'est pas encore ancrée.
Comment vérifier par vous-même
- Consultez les résultats publics et la spécification du format de preuve. Lire la spécification.
- Téléchargez l'archive des outils. Ses instructions permettent de rejouer les tests avec des données synthétiques, sans compte PrivCloud. Télécharger l'archive.
- Pour une preuve réelle, conservez le checkpoint avant un incident, choisissez indépendamment l'autorité, l'origine et le RP ID attendus, puis lancez le vérificateur en mode strict avec votre original. Instructions détaillées.
La vérification d'un document réel reste locale : ne publiez ni l'original confidentiel, ni les sessions de test, ni la clé d'audit de votre équipe. La page publique et l'archive ne contiennent que des outils et des données synthétiques.