Ein Dienst, der Beweise über Ihre Daten signiert, hat eine naheliegende Versuchung: die Daten in den Beweis aufzunehmen. Das würde die Suche erleichtern, den Support vereinfachen und ein reichhaltigeres Dashboard ermöglichen. Wir haben früh entschieden, dass Trustvice-Belege das nicht tun: Ein Beleg enthält den Hash dessen, was er beschreibt, nicht den Inhalt.
Dieser Beitrag erklärt, warum, und wo das Design Sie ohne Ihr Zutun nicht mehr schützt.
Beweise, die weitergegeben werden#
Ein Beleg nützt nur, wenn Sie ihn jemandem geben können: einem Prüfer, einer Gegenpartei, einem Mediator. Alles darin kann lesen, wer ihn bekommt. Trügen Belege Inhalte, würde jeder geteilte Beleg etwas preisgeben, und Sie müssten jedes Mal ans Schwärzen denken.
Ein SHA-256-Hash vermeidet das. Er besteht aus 64 Hexadezimalzeichen, die die exakten Bytes Ihres Inhalts identifizieren, ohne sie zu verraten. Der Beleg sagt dann im Kern: Zu dieser Zeit wurden diese Bytes unter diesem Label vorgelegt. Die Bytes behalten Sie. Wenn es darauf ankommt, legen Sie sie vor, jeder hasht sie, und der Hash passt zum Beleg oder nicht.
Wo Hashen nicht reicht#
Hörten wir hier auf, würden wir Sie in die Irre führen. Hashes schützen Inhalte gut unter einer Bedingung, und einige Felder eines Belegs sind gar keine Hashes.
Ein Hash verbirgt Inhalte nur so gut, wie sie unvorhersehbar sind#
SHA-256 ist nicht umkehrbar, aber erratbar. Hat die Eingabe wenige Möglichkeiten, etwa Ja oder Nein, eine E-Mail-Adresse, einen kurzen Code oder eine bekannte Vorlage, kann jeder mit dem Beleg die Kandidaten hashen und vergleichen. Nehmen Sie bei solchen Inhalten einen Zufallswert, eine Nonce, in das Gehashte auf und bewahren Sie die Nonce beim Original auf. Der Beleg beweist dann die Existenz, ohne Raten zu erlauben.
Manche Felder stehen im Klartext#
Labels und andere Freitextfelder, die Sie wählen, werden im Klartext geschrieben, und sind sie einmal in einen Beleg signiert, bleiben sie dort. Verwenden Sie undurchsichtige Kennungen, etwa eine Bestellnummer oder eine interne ID, und behalten Sie die Zuordnungstabelle auf Ihrer Seite.
Hashen Sie die exakten Bytes#
Ein Hash identifiziert Bytes, keine Bedeutung. Ein Zeilenumbruch am Ende, \r\n statt \n oder eine andere Unicode-Normalisierung ergibt einen anderen Hash. Legen Sie für Text Kodierung und Zeilenenden einmal fest und bleiben Sie dabei. Speichern Sie bei strukturierten Datensätzen die exakt gehashten Bytes, keine Neuserialisierung: Ein späteres JSON.stringify mit anderer Key-Reihenfolge hat einen anderen Hash. Bei mehreren Dateien hashen Sie ein Manifest mit dem Hash jeder Datei und attestieren das Manifest.
Bewahren Sie Ihre Originale auf#
Planen Sie eine Folge ein: Ein Beleg kann den Inhalt nicht wiederherstellen. Wenn Sie das Original verlieren, lässt sich der Beleg weiterhin verifizieren, beweist aber nichts Nützliches mehr über ein Dokument, das Sie vorzeigen können. Speichern Sie Originale unveränderlich neben ihren Belegen.
Löschung und das Wesen von Beweisen#
Eine Grenze kann kein Design aufheben. Ein Beleg, den Sie schon jemandem gegeben haben, bleibt für diesen prüfbar, was immer wir tun, denn die Prüfung braucht nur den Beleg und einen öffentlichen Schlüssel. Genau diese Eigenschaft macht ihn zum Beweis. Deshalb zählt der Rat oben: Halten Sie personenbezogene Daten aus den Klartextfeldern heraus, dann wird das Löschen eines Belegs selten schwierig. Meist genügt es, das Original im eigenen Speicher zu löschen, denn der Beleg hält nur dessen Hash.
Kurz gesagt#
Wir signieren Fakten über Ihre Daten, nicht die Daten. Erst zu hashen bedeutet, dass Belege weitergegeben werden können und dass die Verifizierung nie Vertrauen in unseren Speicher erfordert. Es macht einen erratbaren Wert nicht privat, und es schützt nicht, was Sie in Klartextfelder schreiben. Verwenden Sie Nonces für kleine Eingaben, undurchsichtige IDs für Labels, und bewahren Sie Ihre Originale auf.
Mehr unter Was ein Beleg beweist und was nicht und auf unserer Sicherheitsseite.
Live-Demo