Un service qui signe des preuves sur vos données est tenté : mettre les données dans la preuve. La recherche serait plus simple, le support aussi, et un tableau de bord plus riche deviendrait possible. Nous avons décidé tôt que les reçus Trustvice ne le feraient pas : un reçu contient le hash de ce qu’il décrit, pas le contenu.
Cet article explique pourquoi, et où la conception cesse de vous protéger sans votre aide.
Une preuve qui doit circuler#
Un reçu n’est utile que si vous pouvez le remettre à quelqu’un : un auditeur, une contrepartie, un médiateur. Tout ce qu’il contient est lisible par la personne à qui vous le donnez. Si les reçus portaient du contenu, chaque reçu partagé laisserait fuir quelque chose, et il faudrait penser à caviarder à chaque fois.
Un hash SHA-256 évite cela. Ce sont 64 caractères hexadécimaux qui identifient les octets exacts de votre contenu sans les révéler. Le reçu dit alors, en substance : à cet instant, ces octets ont été présentés sous ce libellé. Vous gardez les octets. Le moment venu, vous les produisez, chacun les hache, et le hash concorde avec le reçu ou non.
Là où hacher ne suffit pas#
S’arrêter là serait trompeur. Les hashes protègent bien le contenu sous une condition, et quelques champs d’un reçu ne sont pas des hashes du tout.
Un hash ne cache le contenu que si celui-ci est imprévisible#
SHA-256 ne s’inverse pas, mais il se devine. Si l’entrée a peu de valeurs possibles, comme un oui ou un non, une adresse e-mail, un code court ou un modèle connu, quiconque détient le reçu peut hacher les candidats et comparer. Pour un tel contenu, ajoutez une valeur aléatoire, un nonce, à ce que vous hachez, et gardez le nonce avec l’original. Le reçu prouve alors l’existence sans laisser un lecteur deviner.
Certains champs sont écrits en clair#
Les libellés et autres champs de texte libre que vous choisissez sont écrits en clair et, une fois signés dans un reçu, ils y restent. Utilisez des identifiants opaques, comme un numéro de commande ou un id interne, et gardez la table de correspondance de votre côté.
Hachez les octets exacts#
Un hash identifie des octets, pas un sens. Un saut de ligne final, \r\n au lieu de \n, ou une autre normalisation Unicode donne un autre hash. Pour du texte, fixez une fois l’encodage et les fins de ligne, et tenez-vous-y. Pour des enregistrements structurés, stockez les octets exacts que vous avez hachés, pas une resérialisation : un JSON.stringify ultérieur avec un autre ordre de clés donne un autre hash. Pour plusieurs fichiers, hachez un manifeste qui liste le hash de chaque fichier, et attestez le manifeste.
Conservez vos originaux#
Prévoyez une conséquence : un reçu ne peut pas reproduire le contenu. Si vous perdez l’original, le reçu se vérifie toujours, mais il ne prouve plus rien d’utile sur un document que vous pouvez présenter. Stockez les originaux en écriture unique, à côté de leurs reçus.
La suppression et la nature de la preuve#
Une limite échappe à toute conception. Un reçu déjà remis à quelqu’un reste vérifiable par lui quoi que nous fassions, car la vérification ne demande que le reçu et une clé publique. C’est la propriété qui en fait une preuve. C’est aussi pourquoi les conseils ci-dessus comptent : gardez les données personnelles hors des champs en clair, et effacer un reçu pose rarement problème. Effacer l’original dans votre propre stockage suffit en général, car le reçu n’en garde que le hash.
En bref#
Nous signons des faits sur vos données, pas les données. Le hash d’abord permet aux reçus de circuler et garantit que la vérification n’exige jamais de faire confiance à notre stockage. Il ne rend pas privée une valeur devinable et ne protège pas ce que vous écrivez dans les champs en clair. Utilisez des nonces pour les petites entrées, des id opaques pour les libellés, et conservez vos originaux.
Pour aller plus loin : Ce qu’un reçu prouve, et ce qu’il ne prouve pas et notre page sécurité.
Démo live