The curse of immutability, and sour pickles

Until recently I had thought of immutability as a Good Thing, in the context of blockchains. It is, after all, one of the most desirable attributes that prevents double spend and enables consensus. The security of the blockchain depends on it.

As my learnings went from Bitcoin to Blockchains to Distributed Ledgers, I made a faulty extrapolation. I did not notice it at the time, and should become obvious as you read on. My aha moment was prompted by a recent Corda training session.

Immutability, as discussed in the context of blockchain technology, is related to the security concept of Integrity.

Integrity is one of the three attributes in the CIA triad (Confidentiality, Integrity, Availability), which is one of the cornerstones of Information Security. Integrity describes the types and levels of assurances for the accuracy and completeness of data, over its entire lifecycle, and of the systems handling the data.

The reason for bringing up the triad is that nowhere in the Common Body of Knowledge of Information Security there is such thing as Immutability. We need to use the proper terms, and this is where we get into a pickle.

For now let’s assume the two concepts are related in such straightforward manner, and ignore the pickle.

Pickling action: take one Immutability, add some brine and it becomes Integrity. Now you are in a pickle. Ignore for now.

Detour: Integrity as a Security Concept

Integrity, as a system or data requirement, comes in several shades of “desirability”, which range from “can’t-live-without-it”  to  “dont-care-for-it”. We usually refer to the first case as a High Integrity requirement.

When something is said to have “High Integrity” requirement it means:

  • We don’t want it to change (Tamper Proof)
  • We want to know if it changes (Tamper Detection)
  • If it changes, we want to put it back (Tamper Recovery)

 

Part of the work on considering the Integrity attributes of a system  includes:

  • Knowing what needs High Integrity (assets)
  • Figuring out how it is achieved, and the  chinks in the armor (vulnerabilities)
  • Identifying who may want to exploit the gaps (the threat)
  • What happens if the gap is exploited (the impacts)
  • Why would they do so (what can be gained, also related to the asset value)
  • How to mitigate the exposure  (Tamper Proof, Detection or Recovery Controls)

 

The whole thing can be described via this concept map, which works for Confidentiality and Availability as well.

Learn this and you can do “Security”

Cryptocurrencies and Integrity

Let’s use that “Integrity” thing we just learned about, and apply it (keep on ignoring the pickle).

Given that blockchains are recording transactions as “the truth” (aka the system state), it would be desirable for those transactions to have High Integrity, right? It will be no good if someone went back and made changes.

Here is a nice description how immutability applies to blockchains.  Cryptocurrencies need to work in hostile environments, where there is no trust between parties. and parties also don’t know each other. The only assurance those parties have is that nobody can change history, and reallocate  the monies. Immutability is the answer to that riddle, as described in the Bitcoin whitepaper.

Everything we have discussed so far indicates Immutability (High Integrity) is an  important property for Cryptocurrencies such as Bitcoin and Ethereum.

How does blockchain achieve this? By making use of one of the coolest cryptographic functions to date: the cryptographic hash. I am not going to explain how hashing works, as I already did that before. This results in following: making changes to data already stored in a blockchain requires to re-work the hashes, otherwise the integrity validations will fail.

Cryptocurrencies blockchain data structure makes altering data very hard, as every block is tied to the one before until block zero (aka Genesis block). Changing something in the middle requires to also rework the hashes of everything that follows. Given how consensus mechanisms operate with public blockchains, people will notice and refuse to accept the new state of affairs.

Notice that I keep referring to Cryptocurrencies as the subject, not Blockchain, when making this argument of Immutability=High Integrity.

Blockchains are not Bitcoin

This is where I went wrong: Blockchains are not Cryptocurrencies, so what works for one may not work for the other (now you are tasting the pickle in all its acidic glory).

I should have known this, but I missed it. I don’t like to be wrong, so I will blame everybody else for my faulty logic.

Much has been said on the topic of Blockchains vs Bitcoin, such as this IBM post, or this one from PwC just to give you some examples. If you read them, you will notice that immutability somehow crossed over from Cryptocurrencies and into Blockchains.

So..what happened?

Hubris happened. On my part, and IBM’s, PwC’s and a lot of others. In the zeal to sell this new technology, everybody (including me) held onto immutability as a selling point. You can find immutability in almost every argument made for Blockchains, as being supportive of whatever use case is at hand.

Instead of referring to a commonly used term such as Integrity, we took something from the world of Cryptocurrencies (namely Immutability) and brought it into a different context (namely The Enterprise).

 

First recorded case of hubris, the Icarus non-Immutable wings: I can fly…..ahhhhhhh. Crash!
It seems this could be a bad argument: Immutability=High Integrity. Let me explain why it is so.

The case for High Integrity in Enterprise Applications

Now that we have moved from talking about Cryptocurrencies, and into Blockchain territory, lets try to figure out what is actually needed. For this section I am going to constrain the argument to the context of Enterprise Blockchains.

High Integrity is a desirable attribute in any system that handles financial data. For corporations listed in North America stock markets, lack of integrity can land you in jail if the corporate ledgers are found to be inconsistent or altered. Same applies to many other jurisdictions, as nobody likes book cooking corporations,  Enron style.

This is why any decently run corporation will implement those controls we discussed early on, to prevent, detect and correct unauthorized changes.

And right there I slipped the Trojan Horse into the fort. Did you see it? I used the words “unauthorized”, which means that someone with authority should be able to correct problems with said books (and transactions). So, if someone with the authority needs to make changes, what happens to the Immutability=High Integrity notion?

 

We got some Immutability! Pull! Pull!… later that night….

Well, now I am making a different kind of point: maybe making changes to ledgers are necessary or needed.

Am I right? Keep on chewing on that pickle.

Wait a minute! That does not make sense!

Correct. I misled you a little bit.

I performed a sleight of hand in the section above, by using the term “ledger” which has a very specific meaning. I was able to do that by blending “ledger” with DLT, or Distributed Ledger Technologies, and equating those with Blockchains, without context.

There is another argument to be made, which to my knowledge has not been settled: are Blockchain and DLT the same thing? Well, it depends on how you define Blockchain.

Now we have three concepts to deal with, all of which are used interchangeably by some (bad idea): Cryptocurrencies, Blockchain and DLT. They are not the same, yet you can find them all mixed up everywhere.

Think about it for a bit. If you read the IBM’s and PwC’s cases above you will notice they use the term “Consortium“, and also DLT/Blockchain. The “Consortium” (aka Business Network) is not positioned as a replacement for an enterprise ERP system, where corporate ledgers reside. Currently this is a hare-brained idea.

Notice I said “currently” as SAP, one of the leading ERP providers,  seems to be working on something. But I digress.

Lets shove this DLT into our ERP! Quickly!

 

The proper use,currently, for DLT and/or Blockchain is for Consortium ledgers, not private ledgers. That’s where the “distributed” comes from, as parties in the Consortium (aka network) share versions of “the truth”. That means “our” ledgers, for all involved parties.

Now we are back into a familiar argument about “trust” and all that. Yes, immutability of those “shared ledgers” would enable trust. Knowing that nobody can change the transactions we all took as completed is necessary.

This is a valid follow up question: do parties in a consensus trust each other? The answer is more complicated than just “yes” or “no”. Parties in a Consortium are not sharing their “inner” ledgers (the ERP thing we mentioned before). They are sharing a different set of ledgers applicable to the Consortium, so they only share what they are willing to.

Another key difference with Bitcoin is that Consortium ledgers are permissioned, meaning the parties use the legal paperwork (aka Governance) to determine who joins (or who gets kicked out). There are no anonymous parties in a Consortium, and they all know each other’s legal teams. That is a non-technical type of “trust”. Remember when I used the word “authorized”? The Consortium as a whole is authorized to change whatever they want to change.

So, to cut to the chase: trust in Consortium is created by the technology (immutability) and also by the governance that is established when the Consortium is setup (the legal paperwork). This is why consensus mechanisms in Consortium don’t implement the “Bitcoin style consensus” (aka Proof of Work). Instead, you will find consensus mechanisms that require parties who know each other (i.e Practical Byzantine Fault Tolerance)

So what am I saying?! Lets try this again

The lesson here is that one needs to be very careful with “Immutability”, and that using it as a requirement needs careful consideration on what is being discussed. Add “Blockchain”, “Consortium” and “DLT” into the mix, and turns into a recipe for building labyrinths.

Immutability should be considered, as it has its place, as a technical-preventive control, but it must not be an absolute. Its use depends on the context, and it should not be confused with Integrity which can be achieved by other means.

I think it is hubris to throw Immutability into the mix without thinking. And I am going to prove it with two cases where Immutability as an Absolutes becomes a Curse.

Let me take two pickles out of the jar for you to try.

 

I want to be immutable.. Wait! Not this way! This is not what I had in mind…

Case 1. Privacy and GDPR

This is straightforward: many new privacy regulations, such as GDPR, include the term “right to be forgotten“. It is about a person’s ability to remove personal data in the public domain. In simpler terms: you should be able to request the complete deletion of that embarrassing video you posted on youtube.

Blockchain immutability is a big impediment for the “right to be forgotten”. Personal data should never be recorded in any blockchain, but it happened. It is still happening. Encrypting the data will not save the day, as all encryption schemes are eventually defeated given enough time.

Heck it happened to me! If you read my previous blog entries you may remember I got some blockchain  certifications. This means my name was recorded in the Ethereum blockchain for all to see, and I will not be able to remove it ever (as long as Ethereum hangs around).

Case 2. Revoking a Private Key

This is a particularly obnoxious case, where for whatever reason you lost control of a private key, and therefore you need to revoke it and get a new one.

Here is the problem: all of those prior transactions are signed with your private key. As the blockchain is immutable, you will not be able to re-do all those transactions with your new key.

There is a solution for this problem when dealing with Cryptocurrencies: quickly transfer all your funds to a newly trusted wallet. What about those smart contracts you also signed? Well, move the tokens from there and kill them (you included a kill event did you?).

If you are using Corda then you are properly stuck. Remember I mentioned a recent Corda training? Well, it seems key management will be an issue.

Corda implements a version of Bitcoin UXTO (unspent transaction output), and that means every node in the Consortium doing transaction validations need to examine the whole transaction history, to validate the UXTOs are correct (no double spend of state).

If you need to change your private key, all those Corda events are signed with it. You will need to get some sort of exception from all other parties you transacted with and either:

  • Close all open UXTO’s into a new ones with the new key, into a new transaction stub.
  • Redo all the transactions with the new key (this will be allowed I think)

 

If your key problem is due to a hack and you are in a hurry, good luck to you.

Conclusion

Accenture discussed immutability as something that is not an absolute. At the time, I almost had a conniption at the idea of someone suggesting an editable blockchain.

 

What do you mean an editable blockchain! I can’t take it!
It seems I was under the spell of hubris.

Is Accenture making a good case? To be honest I think time will tell. Their argument is persuasive, but I have been persuaded before by the opposite argument so I am being cautious.

Here is what Accenture proposed “Editing the uneditable. Blockchain needs to adapt to an imperfect world”  https://www.accenture.com/ca-en/insight-editing-uneditable-blockchain . They were right about GDPR.

And here is what Forrester makes of it “Don’t Dismiss Accenture’s Blockchain Redaction Solution — You May Need It One Day” https://reprints.forrester.com/#/assets/2/77/RES137814/reports   (Okey Dokey.. I am listening….)

Further reading

Blockchain Taxonomies

Some thoughts on “immutability”

Blockchain and GDPR

About the Author

1 thought on “The curse of immutability, and sour pickles

Comments are closed.

Enjoy this blog? If so, spread the word!

%d bloggers like this: