Looking for nails to hit with my blockchain hammer

“If all you have is a hammer, everything looks like a nail.” —Abraham Maslow.

Today blockchain seems to be everyone’s hammer in the world of cyber security.  A Google search for “blockchain IoT” found no less than two news articles per day in September describing the many ways that blockchain can solve security problems in the IoT.  Investment in blockchain startups is forecast to exceed $3B in 2017 on top of the billions being spent by established financial and technology firms hoping not to be left behind.  A lot of people are swinging hammers. Big hammers.

The question is, “Where are the nails?”

Blockchain debuted at the very peak of the Gartner Hype cycle in 2016.  Interestingly cryptocurrencies, the most familiar and widespread blockchain application, showed up two years prior, already sliding into the “Trough of Disillusionment”.  Indeed, I started following blockchain when I first became aware of Bitcoin and its distributed approach to security.  The relevance of a distributed ledger to applications in the Internet of Things (IoT) seemed obvious even if still intimidating given the scale of computing used in Bitcoin.  But relevance is theoretical and I, like many, have been looking for pragmatic application of blockchain in the IoT.

My search once again (see a previous discussion on IoT security) brought me to the team at Adventium after I forwarded an article about blockchain in digital health to their healthcare security team lead and Chief Scientist Todd Carpenter.  Todd is leading Adventium’s Department of Homeland Security project defining security approaches for medical devices.  Todd informed me that they had someone studying blockchain specifically for its application to non-cryptocurrency applications.  So, I engaged Tyler “T.D.” Smith hoping to learn more about how to take advantage of this new security technology in the IoT. 

SN: So, Tyler, why did you become interested in blockchain? 

TD: Adventium is constantly on the lookout for ways to improve secure deployment of lightweight services or components. I thought blockchain had the potential to add capabilities to Adventium’s secure virtualization and secure medical device products.

What have you found to be some of the most common misunderstandings about blockchain?

TD: The first is that blockchain has no inherent concept of privacy – everybody has everything. In a blockchain system, every participant maintains a copy of the blockchain. This means that every participant has a copy of all the data. You can add encryption on top of blockchain, but as with any distributed computing system, maintaining anonymity is nearly impossible. You must communicate with other nodes and they must communicate with you. This exchange inevitably leaks information.  I think most companies engaging blockchain assume that they will get privacy because it is a “security technology.”  This is not the case.

Blockchain is a double-edged sword when it comes to modification of data.  A blockchain is exceedingly difficult to modify, which is one of the reasons blockchain is often discussed in the context of supply-chain. However, this characteristic also means that if you accidentally insert an error into your blockchain, you can’t just revert the change. 

Another problem is scale. A blockchain stores every record in one giant data structure. Storing billions or trillions of records in a blockchain is not practical. Even projects like Storj that just put metadata in their blockchain are running into this limitation.  Blockchain is not cloud storage, and trying to use it as another Amazon S3 is asking for trouble.

Blockchain is not stand-alone security technology.  It has no concept of identity, so common security operations of authentication and authorization require non-blockchain technologies, and all the challenges that come with those technologies. For example, a digital signature is a mathematical stamp that you can put on a piece of data to allow others to verify that you indeed signed it. Cryptocurrencies use digital signatures to verify that the participants in a transaction are really the owners of the currency in the transaction. However, there is no single canonical right way to do digital signatures, and existing approaches are fraught with problems, such as relying on third-party organizations to vet owner identities. I wrote a longer piece about the importance of digital signatures on my blog.

What were your expectations of the application of blockchain when you started your investigation?  Did you see it as a solution to a problem upon which you were working?

When I started to dig into blockchain, I learned that blockchain’s applicability is narrower that the hype implies.  Blockchain has compelling features, but those features come with limitations on the maintainability and scalability of blockchain-based systems. These limitations make blockchain best suited for trustless systems.

A trustless system is one that has no requirements for authentication and authorization.  No requirement for authentication means users do not need to be identified. No requirement for authorization means users do not need permission to interact with the system in any way that they desire.  Blockchain is well suited to support trustless systems.

Clearly cryptocurrencies are an example of a trustless system.  What are some other examples?  Are C2C and B2C digital systems inherently trustless? 

TD: Problems involving physical commodities (e.g., supply chain) and problems involving personal data (e.g., medical records) need authentication – you need to know who has the product or who has access to the records.  Authentication is not provided by blockchain.  Problems involving physical devices (e.g., IoT) need authorization – you need to control who can manipulate a device.  Authorization is not provided by blockchain.

One can think of a blockchain as a digital notary in a courthouse into which anyone can walk.  Digital contracts are an emerging blockchain application that has some potential. In the B2B context, a blockchain provides a decentralized recordkeeping system that can be used where traditional records aren’t practical. Think of emerging markets where governments are in flux – a blockchain lets you maintain a verifiable record that can’t be lost or burned if disaster strikes. However, a blockchain contract doesn’t necessarily help you enforce a contract. Parties might agree on what a contract says, but not on what the contract means.

That’s a very interesting point.  The blockchain in these contracting applications is analogous to high integrity data in an application, but the analysis can still be ambiguous. But I also can see that these trustless systems are completely transparent – that is part of their strength.  An enterprise CIO or COO may not be comfortable with total transparency in applications like supply chain or real time contracting.  Can blockchain be deployed like cloud infrastructure – either public or private?  Since one view of blockchain is that it is a distributed database, is a private blockchain just a private, somewhat distributed database?

TD: The most common answer to the privacy problem is the idea of private blockchains, in which only certain parties can access or append to the blockchain. There is nothing fundamentally wrong with a private blockchain, but making it private marginalizes the blockchain’s benefits; if you’re going to have a private database, why not choose something that’s easier to maintain and more scalable? A good starting position for the cost/benefit analysis of private blockchains is “Is the distribution and immutability of a private blockchain worth its maintainability and scalability limitations?”

These trustless applications also seem to have anonymity which is different than most B2B commercial environments.  How are identities for the sake of commerce managed in blockchain?

TD: Blockchain and digital signing are two different things. They’re often used together, but you can use digital signatures without using blockchain, and you can (but shouldn’t) use blockchain without digital signatures.  A digital signature is much like a physical signature – it’s a special mark you put on data that allows others to verify the authorship of the data. When you get an email from me, it includes a digital signature that, if you use my public key,  allows you to verify that the message has not been manipulated.

Digital signatures allow users to publicly attest that content on a blockchain is correct. In cryptocurrencies, digital signing keys are used to attest that the content of a transaction is correct. Without digital signatures, users could invent any transactions they wanted. Without digital signatures, malicious actors could manipulate the data in a block before the block is signed.  Digital signatures will be a key part of any blockchain implementation.

So that’s a key takeaway – blockchain users should anticipate and integrate digital signatures.  Let’s go back to your comment about the robustness of the blockchain – robustness to the point of being difficult to correct errors.  If I combine this robustness, in a practical way, with the distributed database blockchain represents, the result could have some very valuable properties.  The blockchain ledger would be a database that is durable and potentially low cost.  If implemented on an installed base of small footprint nodes, it could be a cost-effective way to implement reliable, secure storage.  What are your thoughts?

TD:  Yes, a blockchain is inherently exceedingly difficult to modify. Its high redundancy makes it very durable. Blockchain is valuable where absolute rigidity in data is desirable, so it works well when records will never change. A timestamp of recorded temperature and shock experience of an asset using blockchain is a good example, though you still have to trust the sensor to not lie.

But before we talk about cost effectiveness via small blockchain nodes, we need to talk about the block verification mechanism. Every block in a blockchain must be signed, and the requirements for this signature depend on the block verification mechanism of the blockchain.

There are two primary blockchain verification mechanisms: proof-of-work and proof-of-stake. Proof-of-work means that the signature on a block proves that the signer has solved a computationally difficult problem. (In cryptocurrency, this is called mining.) Proof-of-work, by definition, is expensive. Proof-of-stake is different. With proof-of-stake signing blocks is computationally easy but signatures are only accepted from nodes with an established stake. In cryptocurrency blockchains, this stake means the node owns some of the currency.

Proof-of-work is infeasible in low power applications like IoT. Proof-of-stake is computationally feasible, but prompts some questions.  What is the stake? How are nodes authenticated? How can you confirm that a high-stake node hasn’t been compromised? Blockchain doesn’t solve these problems for you, so we’re back to a cost/value question. Is a highly robust database worth the effort of addressing these questions?

You have done a financial evaluation of blockchain used for an Electronic Medical Record (EMR).  Can you explain what you found and how this points to places where the economics of blockchain can be disruptive?

A team from MIT proposed a medical records management system called MedRec that uses a proof-of-work blockchain to track permissions to access medical records. Using Bitcoin’s mining costs as a reference, I determined that signing all the blocks required to track medical records for everyone in the United States would cost billions of dollars.

Blockchain is useful when participants are financially motivated to help sign blocks. MedRec’s model did not adequately account for this motivation.

So “proof-of-work” verification is economically efficient for cryptocurrency, but not for a personal information database like those used for medical records.  Can the cost of “proof-of-stake” be low enough for IoT applications?  What do we give up with “proof-of-stake” and when is the tradeoff worthwhile?

In proof-of-work, anybody can verify a transaction or sign a block. In proof-of-stake, the richest users have more weight than the poorest. The more money you have, the more you’re trusted to sign blocks. Proof-of-stake doesn’t affect the size of the ledger, just the computational difficulty of signing a block.  

In the context of IoT, proof-of-stake has limited potential to allow low-cost blockchain implementations. Proof-of-stake in the IoT would allow robust distributed storage, but with the IoT’s ties to real-world devices, authentication mechanisms external to the blockchain are required to provide security.

I have read about using blockchains for authorization and access controls implemented via the collection of personal and enterprise devices used by a given individual.  I could extend this to devices themselves particularly as they become smarter and mobile.  This seems like a very effective application because it automates the maintenance and control of authorization of devices in multi-device applications – whether personal or enterprise.  Am I missing something?

Passwords are a means of authentication. There are other means of authentication, but blockchain doesn’t help with authentication. Blockchain distributes data and makes it hard to modify existing records, but it doesn’t guarantee that a device on your network is supposed to be there, and it doesn’t give you a new way to provision a new device or grant a new device access. You could store access permissions in a blockchain, but you’d still need a non-blockchain method of provisioning and protecting devices.

Automation is orthogonal to blockchain. A blockchain could store information related to automation, but blockchain itself is a data structure that is agnostic to its application.

SN: I don’t understand.  If machines can talk to each other they could evaluate a request and if consensus is reached, execute a transaction and record it in the ledger – automatically.

TD: Right, but the “magic” in that process is how they evaluate a request.  Blockchain gives you trusted storage of the transaction, but it doesn’t give you a way to determine whether the request is legitimate. Blockchain could be part of automated authentication and authorization, but only as storage.

For example, blockchain could give us a hard-to-modify record of approved MAC addresses, devices IDs, etc., but it doesn’t give us a way to differentiate an authorized device addition from an illicit addition unless the user manually adds information about the new device to the blockchain.

Conclusion

Thanks for these insights, Tyler.  Clearly blockchain is not the security panacea that one may perceive from the hype, but it also has some strong attributes that will be valuable to some IoT applications.  I think we have uncovered five key takeaways:

• Private blockchains are unlikely to offer economic advantage over existing secure key-based secure databases.
• Blockchain works in trustless applications, but with the security comes transparency that can limit utility.
• Blockchain works well for data streams that do not change, e.g. time-based temperature and shock experience of a thing, but developers must remember that the robustness of the distributed ledger comes at the expense of flexibility. 
• Proof-of-stake is more likely to be the right approach to managing a ledger for IoT due to the cost and complexity of proof-of-work used in cryptocurrencies.
• Authentication and authorization are not part of blockchain and have to be added and curated to implement a blockchain-based application.  The promise of automated transactions from blockchain will only be realized with the addition of authentication and authorization techniques.

I believe there is still a lot of value to be realized in the application of blockchain.  I look forward to seeing developers leverage these values to improve both the security and robustness of IoT applications with this technology.