Google trillian-verifiable data storage

1 Introduction

The trillian white paper Verifiable Data Structures pointed out that
life needs to rely heavily on trust in authoritative organizations.
In the network field, the website owner needs to trust the certificate issued by the certificate authority; the mail client needs to trust the key server to return the target mail recipient's public key to be correct; the server administrator needs to trust the software sent by the package distributor binary file.
In the real world, citizens need to trust the Real Estate Bureau to accurately record land ownership.

The corresponding code implementation is: [go language, based on Merkle Tree , constructed in the form of gRPC services. 】

• Google trillian github library

2. Trillian data structure

Based on the trust but verify principle, the following data structure is constructed to make the entire trust model transparent:

• Verifiable logs: Only append-only log is supported. Once an entry has been accpted by the log, it will never be deleted or changed.
  
• Verifiable Maps：为a map from a set of keys to a corresponding set of values。周期性地，该map会发布a signed tree head which includes a root hash of all $2^{256}$ entries。
  
• Verifiable Log-Backed Map：为a Verifiable Map backed by a Verifiable Log，用于描述an ordered set of operations that result in predictable mutations to the map。
  

The characteristics of these three data structures are:

3. Trillian application case

For details, please refer to the trillian application case .

3.1 Used for certificate transparency

In 2013, the Certificate Transparency (CT) rfc6962 memorandum proposed an experimental protocol for publicly recording the existing Transport Layer Security (TLS) certificate, so that anyone can audit the activities of the certification authority and pass the audit certificate The log finds available certificates in time, so that end users can reject certificates that are not recorded in the log, thereby effectively promoting the certification authority to add the certificates issued by it to the log in time.

Based on the memo, the Certificate Transparency vision pointed out that it is mainly used to detect malicious or erroneously issued certificates to build an ecosystem that makes the issuance of website certificates transparent and verifiable.
The main participating companies are:

• apple
• Google
• Censys
• Cloudflare
• digicert
• facebook
• Let’s Encrypt
• SECTIGO
• sslmate

The corresponding code implementation is: [go language implementation]
tls certificate audit-certificate transparency code base

3.2 Firmware Transparency mechanism for device firmware update

For the corresponding code implementation demo, see:

• https://github.com/google/trillian-examples/tree/master/binary_transparency/firmware

Device firmware is everywhere, such as:

• Cell phone
• Watch
• TV
• Alarm clock
• Baby monitor
• WiFi device

For any desktop computer, people are familiar with BIOS/UEFI type firmware, but there are also many other hidden firmware blobs running on small controllers, which power the management engine, keyboard, network card, hard disk/ssd and other devices.

Firmware is powerful and usually requires the highest authority to run, which is the cornerstone of device security.
It is also often almost completely invisible, difficult to understand, and in many cases proved to be insecure and fragile. Such as the risk of peripheral devices: hidden WINDOWS and LINUX inside the computer pointed out: WIFI adapter, USB hub, trackpad, camera and laptop network interface card unsigned firmware provides a variety of ways a malicious attacker, it can Harm laptops and servers.

Nowadays, first-class vendors that provide firmware also provide an update framework that will verify the integrity and authenticity of the firmware update before allowing it to be installed. but:

• Even in this best case, how do we know that the signed firmware is not faulty or even malicious? If the signature used to assert the authenticity of the firmware is used in some way to sign an accidental update (whether through the same thorough compromise as the Realtek logo used to sign the Stuxnet worm , or more subtle through some form of internal risk (no matter Is it malicious or something else) What will happen?
• How did the publisher know that this happened? If they have been compromised, can they trust their key protection or audit logging?
• How do users of the update know if they are getting the same update as all other devices, or just an update specially made for a small group of people?

Therefore, it is necessary to introduce a Firmware Transparency mechanism to ensure that all firmware is discoverable. That is, the same published firmware list is visible to the publisher, to the device to be updated, and to security researchers. Security researchers can use the most advanced static analysis and detection tools to analyze it.

3.3 Synchronize Ethereum transactions to Trillian log

See the corresponding demo:

• https://github.com/google/trillian-examples/tree/master/etherslurp

syncs a popular blockchain into a Trillian Log, and then replays the transactions contained in the blocks into a Trillian Map of SHA256(Account ID) -> Balance.

3.4 Build Trillian apps

See detailed demo:

• https://github.com/google/trillian-examples/tree/master/registers

This tutorial shows how to build a demo application using Trillian that creates a log, and from the log, creates a map, and then serves that map from a webserver.

3.5 Tritter, a chat service with audit function

See detailed demo:

• https://github.com/google/trillian-examples/tree/master/tritter

a deployment which allows authenticated employees at your company to post to a public messaging platform (Tritter) under the company’s shared account. This platform doesn’t support multi-login, so you have created a proxy (TritBot) that takes requests from employees and posts these to Tritter.

TritBot logs each message request with the details of the sender in order to prevent abuse.

3.6 Audit of Go SumDB

See detailed demo:

• https://github.com/google/trillian-examples/tree/master/sumdbaudit

该demo中，包含了tools for verifiably creating a local copy of the Go SumDB into a local SQLite database：

• cli/clone is a one-shot tool to clone the Log at its current size
• cli/mirror is a service which continually clones the Log
• cli/witness is an HTTP service that uses a local clone of the Log to provide checkpoint validation for other clients. This is a very lightweight way of providing some Gossip solution to detect split views.

Reference

[1] Google trillian github library
[2] Trillian corresponding white paper Verifiable Data Structures
[3] Trillian application case
[4] Certificate Transparency (CT) rfc6962 memo
[5] Certificate Transparency vision
[6] tls certificate audit-certificate transparency code base