The Factom Protocol is an open source blockchain protocol specifically designed to provide a decentralized immutable layer for managing pure data. Throughout this article, we will look at how IoT devices can leverage the characteristics of the Factom Blockchain core design features to increase security. Advantages of the protocol will be explained, including the use of a merkle tree root structure to allow for individual chains to be created without restrictions on block size. Additionally, this merkle root structure allows for the concept of thin blockchain clients (i.e. light nodes) that can be used to develop an extensive set of monitoring systems without requiring full copies of the blockchain. Further, this article will discuss a method securing data at the device protocol level at or near the IoT device origin, thus improving data integrity. There are several common blockchain characteristics that IoT developers may use to evaluate when selecting a decentralized ledger to use for their project. These characteristics include: consensus mechanism, cost of entry, block size considerations, block latency, and network latency.
Overview of the Factom Protocol Nodes
The Factom Blockchain Protocol consists of three types of nodes, Federated servers, Audit servers, and Followers. There are no restrictions on who can run a follower node. These types of nodes act as end points to the protocol whereby, entries can be submitted and queries for data on the blockchain can be obtained. Federated and Audit server nodes secure the data onto the blockchain.
At its core, the Factom Protocol uses a multi-leader consensus mechanism based upon the Raft Algorithm, requiring a majority of nodes to agree on each write to the blockchain. The protocol uses federated and audit servers which work together to establish an Authority Set.
Federated servers are the leaders (which are the authority nodes authorized to write entries into the blockchain) and audit servers are authority nodes designated to ensure the integrity of the federated leaders. If at any time an issue arises with a federated leader, the consensus mechanisms within the protocol will promote an audit server and designate it as a new leader. The authority node that is supplanted as a leader is then demoted to an audit server or taken offline until any issues with the server are resolved. The audit servers are the essential reserves that provide failover protection to guarantee uptime and integrity of the network in case a leader crashes, goes offline, becomes unavailable, or compromised.
Both federated and audit servers provide an equal importance to the protocol, whereby an audit server must be capable of replacing a demoted federated server at a moment’s notice. For the public Factom blockchain, both types of servers are equally compensated at roughly 1100 FCT/month to secure the protocol. There are currently 55 servers in the authority set, 28 federated servers and 27 audit servers. The Factom protocol established a governance system to elect authority nodes in early 2018, at which point it became a truly decentralized protocol. The ultimate goal is to finalize decentralization at 65 elected servers in the Authority Set.
The cost of using the Factom protocol is a fixed $0.001 per kB entry. An Entry Credit may be purchased over-the-counter or by burning FCT into Entry Credits. This makes the cost of the protocol predictable, and the user of the protocol does not need to own cryptocurrency to participate, making this an ideal public blockchain for enterprises and governments.
Adding to the security of the Factom Blockchain, an anchoring technique is used that will periodically enter a snapshot of the blockchain in the form of a hash onto both the Bitcoin and Ethereum blockchains. This anchoring adds the cryptographic security of the Bitcoin and Ethereum to Factom. In a theoretical 51% attack, the attacker would be able to take full control of the blockchain network by controlling 51% of the Authority Set. If this occurred, the attacker would not be able to change the past, but only the future because of anchoring to the secondary blockchains. Such an attack would be detected and the blockchain could be forked by the 49% to regain control.
Figure 1: Factom Blockchain increased security through anchoring to Bitcoin and Ethereum Blockchains. (Source: TFA Labs)
The Importance of Merkle Tree Chains for Factom
One of the limitations of many blockchain designs is the size of the entry blocks. The blocks contain all the transactions (i.e. entries) for a given time period. During high transaction / entry submission periods, latency to submission can be introduced which will ultimately restrict transaction throughput. The Factom blockchain does not have this inherent problem, thus chain structure makes the block size virtually unlimited. This is because of the use of Merkle tree style of chains used within the Factom Protocol.
A Merkle tree is a common design structure used within typical blockchains. To create a Merkle tree for a given block, all entries are individually hashed then combined through hashes to create a parent nodes. After all the entries are hashed into parent nodes, the process is repeated by hashing the parent nodes into new parent nodes, until the tree has been reduced to a single hash, i.e. the Merkle root. Thus, the Merkle root contains all the information for a given block in a single hash. When creating anchors to secondary chains, these Merkle roots can be combined to create a new Merkle tree, whereby the Merkle root of that tree can be used as the anchor point.
What makes the Factom Protocol unique is the use of the Merkle Trees to create dedicated chains within the blockchain, which can enable flexible and customized system chain designs. Within the protocol, each independent transaction allows for 10kb of raw data. Entries are submitted to the user chains or can be used to create a new chain.
In the context of IoT, a single device can have its own dedicated chain within the blockchain. Further, light follower nodes can exist whereby only relevant information for a specific series of chains can be monitored. This would allow auditing and monitoring tools to have ready access to only pertinent blockchain data on deployed devices without the need for heavy processing, data storage, or high bandwidth network requirements. All data from a single IoT device can be found with the IoT device information, as all data will be located within the same chain. By having each device have its own chain, device monitoring can be readily done.
Data expected at regular intervals ensures missing data would be rapidly detected and appropriate red flags can be raised. This provides a “Proof of Negative” where you do not need the raw data to find the block chain entry. The evidence of absence can be obtained by following the timeline within the chain. On other blockchains, specific entries can be hidden until the data is revealed.
The cryptography of commit and reveal of data entries is a characteristic of many blockchain designs. When data is submitted it will not be revealed (i.e. made public) until commanded by a supplemental cryptographic information. This provides censor resistance to the data prior to being locked into the blockchain. Generally, one of the ramifications of the commit and reveal technique is you can make many entries and reveal only the ones you want others to see. For example, suppose you want to prove you can predict the winner of every super bowl. In the bitcoin blockchain, you would post all possible predictions, then reveal only the ones that are correct. However, with the Factom Protocol, by revealing one of the entries, you would have revealed your entire “prediction chain”. Therefore, all entries have links to each other by blockchain design, not an external design. If building these ‘chains’ by some external design, the links between entries are not immutable. Thus, the use of Factom chains are designed specifically to create audit trails.
Data resolution is another concern of IoT developers. Not all data needs to be stored on-chain. Common databases can be used in conjunction with blockchain to added a cryptographic verification layer. Multiple database entries can be hashed and signed and submitted as one entry on-chain. This would create an anchor point for the database that can provide a verifiable cryptographic fingerprint of the data within the database. Secondary chains can also be created outside of the Factom blockchain with cryptographic anchor points to the public Factom blockchain. This technique is useful where an enterprise may not want to publish all information to the public chain and adds further protection against DDoS attacks. In the context of IoT, creating secondary chains locally may be useful for maintaining high resolution of the data that is cryptographically verifiable through a low-resolution public entry. The ease of entry and versatility of the Factom Blockchain is what makes the Factom protocol so powerful.
The use of multiple Factom chains for device management is illustrated in Figure 2. In such a use case, four chains could be created.
Figure 2: Device management though multiple chains. (Source: TFA Labs)
In this example, the first two chains would be maintained by the manufacturer and the others by the device itself. The manufacturer could have a high-level chain that has records of all of its device models, with each entry signed by the manufacturer’s private keys, to ensure authenticity.
For each device model entry within that chain, it would point to the chain for the specific device model. That device model chain could contain information such as model serial numbers, the latest firmware versions along with cryptographic signatures for firmware validation, etc.
The third chain would be maintained by the device or owner of the device where it would contain a pointer to the manufacturer and device model chains, as well as keep a running history of time stamped firmware updates, service records, etc. Additional information can be provided such as the health of the device and when it was placed in service or out of service where applicable.
In the fourth chain, cryptographically verifiable raw data generated by the device can be stored. This data would be in the data structures chosen by the device developers along with the cryptographic signatures for the data. It can be a timestamped history of all data generated by that device. There are times when this information can be sensitive or too much data for the public chain. This is where the private chains and secondary database techniques with anchoring discussed above can be employed.
The chain structure design of the Factom Blockchain further allows for a high degree of sharding of data storage enabling the blockchain to scale horizontally. This technique will improve transaction throughput and allow the performance of the blockchain to massively scale as more IoT devices are added. Sharding is not yet implemented within the protocol, however it is a high priority on the development roadmap.
Block Times: A Critical Factor
Block times are another important factor when evaluating a blockchain. The public Factom Blockchain has 10-minute blocks. Longer blocktimes allow for more network stability but have a longer latency for when data is published. Shorter block times come at the expense of requiring more computational horsepower, where block sealing (involving merkle root computations, etc) has to be done more often. In between the 10-minute blocks, data that is going into the next block is available, but queued while being secured into the next block. Another note is when entering data within a block, the Federated Server has only one minute by default to secure that data otherwise the next server will take over responsibility for securing that data element. That one-minute time limit is for a Federated Server to secure the data.
The blockchain infrastructure does not add significant network latency. IoT device signing and hashing would add some latency, however, there are hardware accelerated cryptographic signing and hashing algorithms that can be leveraged to mitigate computational latency. The Entry system for the Factom protocol requires the SHA-256 hashing algorithm with elliptic curve ED25519 Schnorr signatures. At the Authority Server level, the Factom protocol consensus algorithm can handle network latency, and can be dialed on a private chain to handle extremely latency heavy networks, if latency becomes a problem, the fault tolerance can be increased.
For example, the public Factom mainnet has a 2-minute tolerance before a Federated server is replaced by an Audit server. Factom data entries have a period of one hour from when they are signed to when the need to be submitted to the blockchain. This is advantageous for IoT devices that may not have direct access to the Internet or where the data may pass through several subtier networks before making it to the gateway endpoint. Other times, IoT devices can be deployed where network connectivity is intermittent or otherwise degraded.
There are several signing schemes for how data from IoT devices can be entered on to the blockchain. The first option is that the data on the IoT device can create, sign, and transmit the Factom entry ledger directly. This option will require the IoT device to have a funded Entry Credit address.
Another option is that the device can cryptographically sign the data with a private identity key and that data and signature can later be validated and converted into a Factom entry at an endpoint downstream from the device. The advantage to this approach is the validation endpoint can be developed to have custom rules for acceptance, such as accounting for excessive latency. Further, if a device is compromised or otherwise misbehaving, having a validation layer can reject the entry from that device. With this option, the validation endpoint would be responsible for having a funded Entry Credit address.
This is possible because the Factom protocol is simply a raw data layer on a blockchain. Because of this, the user can also design their own custom signature and validation schemes whereby each device could have its own unique cryptographic digital identity with signed data in a data structures designed by the IoT developer and not dictated by the protocol. Custom validators can be established as the endpoints to the Factom protocol that would validate the data prior to submission to the blockchain. Thus, the payment for Factom blockchain entries can be at the validator end point rather than at the device level. If desired, a custom scheme can be developed such that the hashing and signing algorithms can be negotiated via blockchain configuration entries, e.g. in a client-side smart contract. This scheme would allow the developer to take advantage of the latest cryptographic algorithms now starting to appear in IoT hardware and not just be limited to the requirements for submitting a Factom entry.
A structured client-side smart contracts system based upon Petri nets is in active development in the Factom protocol. Client-side smart contracts offer a capability with the advantage of not requiring the smart contract code to be executed within the blockchain similar to Ethereum. Factom Asset Tokens (FAT) are now available on the Factom Protocol as well. This will enable device-to-device transactions to be possible within the ecosystem.
Security Solution, Signing Data at Source
One major vulnerability within IoT devices is that data can be altered before or during transport to the destination, or even at the destination itself. The solution to this problem is cryptographically signing the data at the source. To accomplish this, the private cryptographic keys must be secure and tamper proof on the device. With this, the device can establish a digital identity that can guarantee data was generated by the device. Data validation can also be done with the IoT device public key to prevent Sybil or false data. Device replays are caught from the chain structure, restraining each data point within the chain to one IoT device.
To ensure the keys are kept safe and tamper-proof, specialized secure microprocessors exist such that the private keys can be operated upon in a secure trusted environment within the IoT device. One such device is the IOT-SAS (Signed at Source™) microcontroller. The IOT-SAS IC is a small surface-mount device (SMD) that is intended to be embedded within the IoT device by adding a secure cryptographic microprocessor with tamper-proof secret identity key that can be augmented into existing devices and network configurations. This ensures the integrity of the data through transport by cryptographically signing the data for blockchain entry as close to the source as possible. IOT-SAS supplements an IoT device’s operation by providing a tamper-proof secure way to sign entries intended to be submitted onto a blockchain. The device does not require, nor support direct network connectivity. The IOT-SAS communicates via an I2C or UART serial message bus to the IoT device or a single board computer that can act act a bridge device. Adapters are available for Arduino, Raspberry Pi, and Meadow devices for proof-of-concept testing.
IOT-SAS Surface Mount Device (Source: IOT-SAS)
IOT-SAS integrated with Raspberry Pi (Source: IOT-SAS)
The IOT-SAS SMD also helps prevent Sybil attacks on devices. In a Sybil attack, devices with false identities would join the network. Since the devices would be authenticated by the issuer, any Sybil attack would require the issuing authority of the device to be compromised. If this is the case the issuer must take the device offline. One unique feature of the IOT-SAS solution is the cryptographic keys are generated inside the device during the one-time configuration of the board during the initial one-time flashing (i.e. initial programming). Thus, the secret keys never exist outside the cryptographic chip, which helps mitigate this type of attack.
Figure 3: IOT-SAS illustration to create secure digital identity. (Source: IOT-SAS)
Both AWS and Microsoft Azure both provide centralized cloud service offerings for IoT devices. One of the features of these offerings is the ability to create device shadows that can be used to simulate IoT devices. So what would happen if a device shadow was also publishing to the real device’s chain on the Factom Blockchain (and the Factom protocol was integrated with these IoT cloud offerings)? A real device using the IOT-SAS hardware would have a unique digital identity that cannot be spoofed, and this includes device shadows. Thus, the digital identity of a device shadow will be either different (if programmed as such) or nonexistent. Using the Signed at Source hardware, data from the real device submitted to the blockchain would be digitally signed by the private identity key on the IOT-SAS hardware. As a developer, the Factom Blockchain entry could be designed such that it stores both the data and the cryptographic digital signature of that data on the device’s chain. In this example, the public identity key would also be published in a separate chain when that device was first registered. The signature of the data in the entry can then be validated. If the shadow was also publishing to the device’s data chain, the user would readily identify that data as either invalid or simulated because it would have an invalid signature (or no signature at all). Thus, that data can be simply ignored or treated differently by the user.
IoT data secured with the Factom Protocol, used in conjunction with Signed at Source hardware, is guaranteed to be secure from the origin. The protocol is decentralized and additional security for the Factom Blockchain is provided through anchoring to the Ethereum and Bitcoin blockchains for total immutability. The cost is fixed at $0.001 per entry without the need to own cryptocurrency. End-to-end security can be readily implemented through the Factom Protocol’s flexible and straightforward programming interfaces. Currently, the Factom Protocol is being used by the US Department of Homeland Security to help secure monitoring devices for improving border security.
Dennis Bunfield is CEO of TFA Labs and IOT-SAS (Signed At Source). Dennis has over 25 years of professional experience in software development for high performance real-time hardware-in-the-loop simulations. His expertise includes vast knowledge of embedded systems and cryptography.