Verification of db data about trillian-examples HOT 1 CLOSED

[copying the answer from Slack to the same question here in case it's helpful to someone else coming along later]

Hi Natalia, in a real application there would be (broadly speaking) two roles which would do this checking (for discussion about the roles themselves see here: https://github.com/google/trillian/tree/master/docs/claimantmodel):

• a believer would want to convince itself that a "record" (claim statement) that it holds is present in the log before taking any action based on the contents of this claim, which it would do by requesting an inclusion proof for H(claim statement). If the client got this claim from the log after it had been tampered with, the log would be unable to provide a valid inclusion proof to any consistent log checkpoint
• a claim verifier would be periodically fetching updated checkpoints from the log to learn about new "records" (claim statements) integrated into the log. When it sees a larger checkpoint it'll fetch the new claims which have been added to the log in order to inspect them. Internally, as it scans through these new claims, it would attempt to recreate the root hash from the new checkpoint by incorporating the H(claim statement) into its local "compact representation" of the source log state. Here again, if the entry in the log had been tampered with, the recreated root hash would not match the one in the checkpoint and so the tampering will be detected.

As a log operator, you may choose to implement a "log scrub" type tool which periodically does this checkpoint root hash recreation from log entries process as an early warning of sorts that something is wrong/tampered with.

Ultimately, though, if anyone ever relies on the tampered data in the future it should be detected because no believer or verifier should blindly trust a claim without convincing themselves that it is discoverable by virtue of proving its inclusion in the log.

HTH!

from trillian-examples.