Overview
In this tutorial, we are going to understand the Security aspects of Ceramic. This tutorial cover all the possible attacks or hack that could take place and respect to that attack or hack what measures are taken by Ceramic.
Introduction
Note
If you are someone who has no idea what is Ceramic then we highly recommend you to read this tutorial -Ceramic Network
Before getting into the security aspect let's understand what is Ceramic.
What is Ceramic?
Ceramic is a decentralized network for composable data.
Ceramic makes building applications with composable Web3 data as easy as browsing a marketplace of data models, plugging them into your app, and storing, updating, and retrieving data from those models. When different applications reuse the same data models, their data is automatically interoperable. By decentralizing application databases, Ceramic makes data composable and reusable across all applications.
Security
In this section, we will be going through various security aspects of the Ceramic protocol and miscellaneous systems like 3ID Connect.
Ceramic Protocol
The main security properties that makes up Ceramic are cryptographic signatures, proof-of-publication (through blockchain anchors), and hash-linked data structures. Together these properties allow the construction of a verifiable data structure. In addition to this Ceramic relies on libp2p pubsub to gossip about stream updates.
Stream data structure
In general, streams are made up of commits that are linked together as a DAG using hash links. This data structure is represented using IPLD. Commits always contain some sort of proof, usually this is a signature or a proof-of-publication. When a Ceramic node syncs a stream this linked DAG of commits can be verified locally and thus be fully trusted.
A proof-of-publication is a proof that some content was published at some point in time. This is achieved by publishing the hash of the content on a blockchain. These proofs can be made more cost effective by putting multiple content hashes as leaves in a merkle tree and only publishing the root. The proof-of-publication provides a definite ordering of events in a stream, which is useful when you want to do key revocation in a secure manner.
For a detailed description of these benefits reference the Merkle-CRDTs paper.
Conflict resolution strategies
Different StreamTypes in Ceramic may have different conflict resolution strategies with different security properties.
The earliest anchor rule solves any conflict in the history of a stream by picking the stream that was anchored at the earliest point in time. This enables keys to be securely revoked since someone that gains possession of an old key after it was revoked will be unable to produce a proof-of-publication that is earlier than the first anchor. This is used in the 3ID DID Method which registers a set of public keys associated to a DID URL, when the 3ID stream is updated with new public keys, revoking the old keys, an outside observer can be sure of the state of the 3ID without any secondary sources of information. 3IDs are built on top of the TileDocument stream type, and alternative DID methods could also be built on top of it.
A drawback with the earliest anchor rule is that the controller of the stream can create anchored commits in secret and reveal them at a later point in time to change the history of the stream. There are various ways to mitigate this. One of them is to only allow anchor services that actively publish all created anchor commits when they are created.
The latest nonce rule solves any conflict by simply picking the signed commit which includes the largest nonce. This strategy doesn't support key revocation, so the controller of a stream with this strategy can't be changed.
Note
Ceramic doesn't support this strategy yet, but it is required for StreamTypes like DIDPublish. In the future The Caip10Link StreamType may also be updated to use this strategy for efficiency reasons.
Network gossip
Ceramic nodes use libp2p pubsub to gossip about stream tips. The two operations that happen in the gossip is publication of stream updates and queries for tips by nodes that load a specific stream. The main security consideration for a Ceramic node is that any new tip that comes in for a stream which it cares about could be a fake or invalid tip for that stream and thus needs to be verified
DoS attack
Issue - A malicious node can spam the pubsub topic by sending a lot of messages. This may be randomly generated messages that are not even for valid streams, or it could be invalid tips for valid streams that get rejected by the stream update rules.
Solution - The main counter attack for this is to limit the amount of messages a single node can send by having an automated reputation system that disconnects from nodes which are spammy. No such reputation systems exists in ceramic today, though it is planned as a future improvement.
False log attack
Issue - A malicious node can spam nodes that pin specific streams by sending faulty commit logs. The unsuspecting node would sync the log of the stream and find it invalid, at which point the node would throw out the faulty log without applying it to its local copy of the stream's state. However, if the false log is long and the malicious node sends multiple of these it may cause a significant amount of overhead.
Solution - The most simple countermeasure to this is to simply stop accepting tips from nodes that have proven to not be reliable.
A more significant approach would be to build a StreamType that includes a recursive zero-knowledge proofthat the log is indeed correctly associated with the given streamid.
Caip10Link clock synchronization
Issue - Currently the Caip10Link streamtype relies on system time on the client machine to mitigate replay attacks. A new update to a Caip10Link stream is only valid if the proof includes a timestamp that is larger than the timestamp of the previous update. This presents a problem however if the users system time for some reason is incorrectly far into the future. Users would at this point be unable to prevent a replay attack using a proof created on this machine. The replay attack could be used to reset a Caip10Link to point to any DID it had previously been linked to.
Solution - A possible workaround could be to switch to using a nonce which is always incremented by one, or include the prev pointer to the previous commit in the proof.
Conclusion
We have completed the Security aspect of Ceramic. If you want to deep dive into Ceramic protocol, Network do check out the Resource section.
Join Discord to discuss or talk with Ceramic developers.