Opinion from Dr. Andreas Freund, EEA Mainnet Interest Group Member

Blockchains have a seldom talked about problem which is independent of the ups and downs of crypto markets, and which can hamper longer term Blockchain adoption outside of direct-to-consumer and some B2B use cases: Blockchain cryptographic algorithms are not NIST compliant which is a major factor in achieving compliance with FISMA (Federal Information Security Management Act)! And NIST/FISMA compliance, or the equivalent thereof outside the US, is a big thing when enterprises deal with governments or enterprises that regularly deal with enterprises dealing with governments.

Why are Blockchains typically not NIST compliant? Well, the main reason is that Blockchains were born out of the deep mistrust of anything government-operated and endorsed in the wake of the Great Recession of 2008; including government-endorsed cryptographic algorithms. In any event, the SHA-3 hashing algorithm widely accepted today was not finalized until 2015 after Blockchains such as Ethereum had already made their choices on hashing algorithms. Therefore, most Blockchains such as Ethereum are using algorithms that are not only not NIST-approved, but that NIST recommends not using. Note, there are NIST-compliant Blockchains such as Simba-Chain or Fabric operating on IBM’s LinuxONE. However, they are high cost and difficult to manage in production[1] as enterprises learned after spending some tens of millions of dollars on consulting and implementation fees. Compounding the cost problem is that they often do not yield the expected business outcomes because the chosen use cases were not suited for Blockchains to begin with! The main takeaway for the discussion below is that any new Enterprise Blockchain approach must address not only NIST-compliance but also both cost and management complexity effectively to attract new business sponsors.

Does that mean that everything is hopeless for Blockchain in an enterprise when NIST compliance, cost and management complexity are a concern?

Luckily, the answer is no, it is not hopeless. Not trivial, but not hopeless.

To understand what this means, let’s recap what characteristics Blockchain-based applications can have:

  • Data Integrity: If you only need that, then do not use a Blockchain. There are cheaper alternatives.
  • Provable Timestamping: Much more interesting and useful for audit trails, e.g. across supply chains.
  • No single-point-of-failure: If you need 100% availability, at a low price.
  • Censorship resistance: Access to data that for example needs to be audited by 3rd parties not necessarily identified at the time of data creation, or executing (basically) irreversible transactions independent of any 3rd party.
  • Double-Spend Protection: Only relevant if you are dealing with digital assets on a Blockchain. In other words, you are really into DeFi.
  • Inheriting Blockchain Security Guarantees: That one is very interesting, if you need application scalability, yet high security. We will get to that in a bit.

Note that none of the above talks about data privacy, one of the priceless jewels of enterprise application requirements. But no worries, you can achieve data privacy without plastering business-sensitive data everywhere out in the open. We will get to that in a bit too.

Before we get ahead of ourselves, let’s pause here and discuss how these characteristics relate to NIST compliance. At first glance, not so much, but let’s go through each characteristic and discuss its implications in a bit more detail. First, though, it is worth mentioning that to obtain Authority-To-Operate (ATO) permissions from a government, e.g. the US government[2], it is ok to use non-NIST compliant cryptographic algorithms, or algorithms that NIST has not formed an opinion about, as long as those algorithms are not fundamental to the security of the application and the privacy of its data. For example, you need to prove that a contract was executed on a specific day and has not been altered since. Using a Blockchain, one would form a cryptographic fingerprint using a (NIST-approved) cryptographic hash of the contract, and then anchor that hash on a (public) Blockchain which provides, once included in a block, a provable timestamp through the combination of block number, block hash, and timestamp. If the Blockchain were reorganized, for example through a 51%-attack, it would still be possible to take the transaction with the contract hash, and its block and include both in another (public) Blockchain. Therefore, the security of the original (public) Blockchain is not fundamental to the use case.

With this in mind, let’s look again at each characteristic, with a focus on its impact on NIST compliance of an application using Blockchain technology:

  • Data Integrity: This one is easy since you can always have a copy of the relevant data you anchored e.g. via a cryptographic hash on the Blockchain with another form of data integrity protection such as a tamper-evident W3C Verifiable Credential with a NIST-approved cryptographic signature algorithm.
  • Provable Timestamping: A bit harder but doable. If the utilized chain were compromised, one could still grab the block with the relevant transaction containing e.g. a NIST compliant cryptographic hash of a document, and its timestamp, and anchor the entire block with the transaction through another NIST compliant cryptographic hash on another Blockchain; no real harm done.
  • No single-point-of-failure: Ok, so this is a bit tricky since NIST has not formed recommendations on consensus algorithms. That means as long as the consensus model has a solid academic foundation, e.g. a mathematical proof of security, it can be successfully argued for, and we put it in the not-not-NIST compliant bucket.
  • Censorship resistance: This sounds like an easy one but because it means that data will be readily visible to (almost) all participants, great care must be taken to use the right obfuscation methods for data put on a Blockchain, to successfully argue that data privacy is maintained. So that one is a bit tricky but can be overcome. Hang on tight, coming right up.
  • Double-Spend Protection: Now this one is really hard because it combines the previous points with deterministic transaction execution, transaction validation, and block formation which all rely intricately on the cryptographic algorithms used. Without going into details, if you need double-spend protection as a key feature in your Blockchain-based application, you are out of luck as to NIST compliance … if your digital asset was born on the Blockchain! We will come back to that point in a second too.
  • Inheriting Blockchain Security Guarantees: This seems to be clear-cut. If your security relies critically on the security of the underlying Blockchain, and that Blockchain relies for its security on not-NIST compliant algorithms; end of the story. Again, not so fast. The question is security guarantees for what? If it is for digital assets born on a Blockchain, then the answer is the same as for Double-Spend protection. But, if the digital assets are created off of the Blockchain first, and only then replicated onto the Blockchain, the security of that digital asset is no longer fundamentally tied to the underlying Blockchain, and we have the same argument as for provable time-stamping to wiggle ourselves out of the NIST conundrum!

The above impact assessment can now serve as a checklist against a Blockchain application’s NIST compliance needs, given the specific use case requirements of that application.

Before moving on and giving an application blueprint for a not-not-NIST compliant Blockchain-based application, let’s talk about data privacy. Given the above criteria, and existing data privacy regulations, putting even encrypted data on a Blockchain qualifies as a dumb idea, even when using NIST compliant encryption algorithms. So what is the alternative?

Answer: Zero-Knowledge Proofs (ZKPs)

ZKPs are about making statements without revealing underlying sensitive data, e.g. ACME corporation’s account balance is over $100,000, or this discount code was properly applied to this order.

There are many types of useful ZKPs – Merkle Proofs, Pedersen Commitments, Bulletproofs, ZK-SNARKs, ZK-STARKs, and so forth. The key is to use either NIST compliant or not-not-NIST compliant cryptographic algorithms when using ZKPs. Otherwise, go for it! ZKPs are a great tool for enterprises to meet their data privacy requirements both internal and regulatory.

Now we are at a place to make a sensible recommendation on how to build a (not-not) NIST compliant Blockchain-based enterprise application – a blueprint.

As the figure shows, we start with a traditional enterprise software stack on the top – first, the application layer, then the application abstraction layer and then the middleware layer – with all the required compliance e.g. NIST compliance built-in. At the bottom of the stack, we have a public Blockchain because that obviates the need for enterprises to build complex consortia, spend a lot of money, and allow them to move much more rapidly with the development of new products. Between the middleware and public Blockchain layer, is the “magic” processing layer focused on privacy and speed. Since the stack will use privacy-preserving ZKPs and not primarily utilize digital assets created on the public Blockchain, previous concerns about the usage of public Blockchains are suddenly gone. As the up and down arrows on the left of the figure indicate, stack security increases as we go from the top layer to the bottom, the public Blockchain. The exact opposite happens with the other three key characteristics – privacy, speed and control; they increase from the bottom layer to the top layer where a single enterprise has full control of all data, and can therefore ensure privacy while maintaining high speed / scalability even for the most sensitive data. That does not mean, however, that privacy, speed and control is low towards the bottom of the stack, it just means that it is higher in the top layers of the stack than at the bottom.

Now, what about that “magic” processing layer/network?

Here is what that layer can do using existing technology to meet enterprise requirements:

  • Data Privacy
    • Zero-Knowledge Proofs of transactions
    • Strong encryption (where required)
    • Latest cryptography techniques e.g. quantum-secure algorithms
  • Security
    • Inherits the security guarantees from the public Blockchain when using the right ZKPs anchored on the Blockchain
    • Digital asset data can be directly available via ZKPs on the public Blockchain to be used if required
  • Verifiability
    • Anyone can verify proofs on the public Blockchain
    • Proofs can recursively verify all asset transactions and the entire asset transaction history
    • Nothing is finalized until proofs are verified on the public Blockchain
  • Speed
    • Parallelization of transactions
    • Rolling up transactions by batching them with (recursive) Proofs
    • Less cost per transaction

In summary, the “magic” processing layer has

  • the same security assurances as the public Blockchain used,
  • 100 – 1000x more scalability,
  • guaranteed data availability,
  • privacy preserved at all times,
  • much lower transaction fees,
  • verifiability of all proofs by anyone on the public Blockchain
  • allows for KYC and AML

This sounds too good to be true. Does such technology already exist? The answer is yes, and companies such as Starkware, Aztec, zkSync, and others are working on getting their ZK-Rollup “Layer 2” technologies fully enterprise-ready. The focus for all these efforts is public Ethereum because it offers the highest security guarantees (number of miners/validators and total-value-locked (TVL)), combined with the required cryptographic support built into its execution layer.

Naturally, this is not the only possible approach for a Blockchain-based application to obtain a government ATO. However, it is a fairly straightforward, and by now well-understood approach.

So what is the net-net here?

Enterprises now have

  • A framework to assess use case needs versus Blockchain characteristics, and how these needs can be met by Blockchain-based enterprise applications that can obtain a government ATO.
  • A blueprint to build Blockchain-based enterprise applications in a way that would allow them to obtain a government ATO while, as depicted in the figure above, also allowing for additional benefits:
    • Higher Trust through public Blockchains, public verifiability and cryptography enforced privacy
    • Lower Cost through easier auditability (verifying ZKPs is fast and cheap) and fancy transaction batching (rollups) in the Layer 2 application
    • Faster Processing through parallelization of compute, more transactions through rollups, and a smaller Blockchain footprint since public Blockchains are supposed to be slow by design in order to provide more security
    • More Flexibility and Choice through the ability to have traditional assets to underpin crypto assets on the Blockchain, simpler integration between Layer 2 and a public Blockchain, and easy extension of layer 2 assets into for example the existing DeFi ecosystems

In closing, it is important to note that in the example of the US government, obtaining an ATO for an information system is not just limited to cryptographic artifacts and crypto-modules. These represent an important piece of the security controls that are identified during the risk management process necessary to obtain an ATO, as listed and explained in expansive detail in NIST SP 800-37 Rev 2 and NIST FIPS-199. The process also  includes elements such as user authentication/authorization under different usage scenarios, system and process change controls, disaster recovery, and business continuity.

Is ATO/NIST compliance for Blockchain applications relevant to your business?  The EEA ATO Working Group would like your input.  Please contact [email protected].

Follow us on TwitterLinkedIn and Facebook to stay up to date on all things EEA.