"Blockchain" is one of the hottest technology industry buzz-words of 2017. A lot of time, money, and engineering talent is being invested into building blockchain technologies. Despite the name, blockchain has nothing to do with the Cipher Block Chaining mode of encrypting large messages with a block cipher; instead, it's used to refer to a [specific type of ledger](https://gist.github.com/joepie91/e49d2bdc9dfec4adc9da8a8434fd029b), and more specifically to crypto-currencies like Bitcoin and Zcash.
As a technology company that specializes in application security, applied cryptography, and code auditing, we get a lot of emails and questions at technology conferences that fit into this formula: "**We have `$problem`. Can we use blockchain to solve that?**" Sometimes the answer is "**Yes**", but in most cases a blockchain is total overkill for the problem that needs to be solved.
With that in mind, we'd like to introduce our latest open source project, **Chronicle**, which may solve your problem without [committing to a blockchain to solve inappopriate problems](https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture).
# Chronicle: Public Append-Only Data Ledger
**Chronicle** is a self-hostable microservice, built with [Slim Framework](https://www.slimframework.com), that provides a [sapient API](https://paragonie.com/blog/2017/06/hardening-your-php-powered-apis-with-sapient) which enables authorized users to commit arbitrary data to an immutable, append-only public ledger.
Chronicle is a lot like [Certificate Transparency](https://www.certificate-transparency.org), except it uses a different data structure and is designed to accept arbitrary data rather than just TLS certificates.
Chronicle's *append-only* property is guaranteed by the following mechanisms:
* Cryptographic Security
* Every record is hashed with BLAKE2b, a hash function faster than MD5 and more secure than SHA256
* The hash of the previous record is used as the key for the current hash
* Additionally, a summary hash is provided, which is the hash of every record's hash since the beginning (the hash state is cached with each record, for optimization purposes)
* Decentralized verification
* Your Chronicle can easily cross-sign its latest hash and timestamp to other Chronicles
* Other people can easily set up a system that replicates and verifies each new record in realtime
In order for an attacker to be able to forge a previous entry in a Chronicle, they will need all of the following:
* Privileged access to the Chronicle being targeted
* Privileged access to every Chronicle that replicates the target Chronicle (including any that are offline)
* Privileged access to every Chronicle the target cross-signs onto, as well as theirs, recursively
* Access to one or more of the Ed25519 signing keys used by the target's clients
Given sufficient cross-signing and replication, in order to reliably compromise the append-only property of any Chronicle, you must be able to completely compromise *every* Chronicle in the universe.
(This is without taking offline backups into equation which will make silent, reliable attacks harder to pull off.)
How to use Chronicle to Effectively and Easily Solve Difficult Problems
Userbase Consistency Verification
As we've previously covered, **UCV** ([**U**serbase **C**onsistency **V**erification](https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers#decentralized-authentication)) is a core component of [secure code delivery](https://defuse.ca/triangle-of-secure-code-delivery.htm), which is itself a building block of a secure automatic update system.
Adding UCV to an existing automatic update system is rather easy. All you need to do is add a trigger on the update server to send the following information to a Chronicle instance:
* The fully qualified name of the project being updated (e.g. `vendor-name/project-name`)
* A secure cryptographic hash (e.g. BLAKE2b) of the update file's contents
* Any other relevant metadata, such as the git commit hash
Upon successful data insertion, Chronicle will return the hash and summary hash of the new record which can be stored in the update server.
When the application fetches the update file as part of an automatic update process, the server can provide one or both Chronicle hashes in an HTTP header (alongside the Ed25519 signature of the update file, provided by the vendor to the update server). The application can then query the same Chronicle to affirm that there is a point-in-time record of this update information, and fail if it is not. This ensures only publicly committed software updates will ever be applied.
Additionally, the association of vendors and their public keys (along with revocations) can be recorded in the same Chronicle, to obviate the need for a central certificate authority or complicated PKI for vendor public key changes.
Proof of Knowledge
Security researchers often publish precommitment hashes on Twitter, then reveal the plaintext at a later date, to prove they possessed knowledge at a given point in time. Chronicle can be used to solve this problem without requiring explicit trust in Twitter.
To achieve this, you can either publish a hash output of a message to your Chronicle, or commit the entire encrypted message and then reveal the encryption key at a later date.
Chain of Custody Verification, Without a Blockchain
If you have sensitive information, you can write metadata about client access times to a private Chronicle in order to have verifiable, tamper-resistant proof that specific records were accessed by specific user accounts at a specific time.
More generally, you can create an immutable log of security events by committing data about these events to Chronicle.
The Next Steps
Chronicle is still being developed on Github, but its version 1.0 release is around the corner. Once we have crossed that threshold, we will set up two instances:
* A restricted Chronicle, for which we will only grant access to a select few software projects
* A public Chronicle, for which we will grant access to any open source software project, which cross-signs onto the restricted instance at a set but undetermined rate (e.g. every 10,000 messages or 30 days, whichever happens first)
The intended purpose of the restricted instance is to allow large software projects, such as [Joomla!](https://www.joomla.org/), to run their own public Chronicle that logs plugin/extension updates and cross-sign onto our Chronicle. We'd also like to stream all updates on [Packagist](https://packagist.org) to a dedicated Chronicle that cross-signs to our restricted Chronicle.
However, the scope of Chronicle extends far beyond the PHP community. Armed with a [Sapient](https://github.com/paragonie/sapient) HTTP client and a Chronicle instance, any software ecosystem can add userbase consistency verification to their automatic update process. Used in conjunction with [The Update Framework](https://theupdateframework.github.io/), the software industry will soon be able to solve the problem of secure code delivery at scale, with minimal effort.