This article has been updated since its publication with further information concerning HHS Accelerate.
The Institute of Electrical and Electronics Engineers (IEEE) has co-published an assessment of how four blockchain platforms measure up against the rigorous security requirements of the U.S. Federal Government and according to the report, only one of the platforms has passed the test.
While the IEEE isn’t a decision maker for what the federal government adopts, it can have a view on what it is likely to do by assessing blockchain providers against the government’s own vetting rules that are used to guide federal adoption of technology.
The Federal Information Security Management Act of 2002 (FISMA) requires that all new federal IT programs and modernization efforts using blockchain meet National Institute of Standards and Technology (NIST) cryptographic standards. If the technology doesn’t meet them, then the federal government cannot use the technology.
However, the ramifications to blockchain adoption are far broader than just being confined to the government, as businesses tend to follow the government’s adoption of certain technologies.
The reason why is because of the outsized role that the government plays in technology procurement. NIST is responsible for providing the Federal Information Processing Standards (FIPS) which are a series of documents which provide technology standards in the government. Because the government is such a large buyer of technology, these standards have become the general de-facto standard for computing more generally.
So if the government doesn’t allow it, companies in other industries are also probably following the same rules and may also decide not to adopt the technology.
The study, co-published by the IEEE Computer And Reliability Societies, and authored by James P. Howard II from Johns Hopkins Applied Physics Laboratory and Maria E. Vachino from Easy Dynamics Corp. scanned the market for blockchain solutions then whittled them down to four platforms based on three criteria; (i) the device is supported by a single, business or consortium responsible for developing standards and guiding future work (ii) the system allows independent, private chains without limiting the application to a single global network (iii) the technique is well supported by developer libraries that allow software developers easy access to data and protocols of the blockchain system.
According to the report, the four platforms which fit the bill were Ethereum (implemented in a private configuration), Hyperledger Fabric, Corda, And Multichain. These were then evaluated against the NIST framework.
Of the four platforms, only R3 Corda was identified as meeting NIST standards and therefore being able to be implemented in federal government projects.
Corda passed as it uses SHA-256 for transaction sealing and SHA-256 is an acceptable hash algorithm according to NIST. Java has many implementations of SHA-256, and there are NIST approved libraries. Corda supports numerous digital signatures. RSA is supported with SHA-256 as the hashing algorithm. For ECC, P-256 is also supported with SHA-256 as the hashing algorithm. All of these have been validated by NIST.
Hyperledger Fabric, Ethereum and Multichain didn’t fit the bill for a variety of reasons, either because the encryption standards used were not approved by NIST, or where they were, they were written in programing languages and libraries that NIST has not approved.
Hyperledger Fabric had NIST approved transaction sealing and digital signature cryptography but as it was implemented in go-lang which is a language implementation not approved by NIST it didn’t pass.
Ethereum had more issues. Ethash, which is used for Proof of Work doesn’t meet NIST requirements and the report saw that the move to Proof of Stake as being a “moving target” which was hard to evaluate. For digital signatures Ethereum uses the secp256k1 curve which has not been validated by NIST
Multichain came close. With a NIST approved cryptography for transaction sealing but support only for secp256k1.19 for digital signatures which has not been validated by NIST.
Corda’s upper hand in government compliance is through a combination of using encryption protocols that are validated by NIST as well as through implementing them in a an established 25 year old language that NIST is familiar with – namely Java.
From Hyperledger Fabric’s perspective, there’s a good argument to be made that go-lang is a new, modern language that has been around for twelve fewer years than Java and Java’s use is therefore more established so it’s only natural that NIST, representing the conservative nature of government (much of which still runs on tried-and-tested COBOL code from the 1970’s) would focus on an established language.
All is not lost for Hyperledger Fabric as it’s entirely possible that we may see NIST spending the time in the future to validate encryption algorithms written in go-lang which may open up Hyperledger Fabric for use in the federal government. However, that is not something to take lightly as NIST has an extensive catalog of vulnerabilities associated with various languages and frameworks, with this level of attention to detail, approval is likely to be a rigorous and long endeavor.
Corda may be the winner but there is an important caveat – Corda meets NIST standards only if ‘traditional java libraries’ are used. To understand this important nuance requires an appreciation of the fact that Corda is actually built using Kotlin, a relative to the Java language which is interoperable with Java.
So why was NIST not able to approve encryption code written a new language such as go-lang, yet a newer language like Kotlin was found to be acceptable?
The answer is NIST approval is only for encryption libraries written in Java which Kotlin, by being a close relative to Java is able to use. If users use Kotlin libraries for encryption, Corda may not pass the NIST test.
Luckily, unlike Hyperledger Fabric, Corda can have it both ways – the advantages of a powerful new language as well as the safety of an established one.
New Technology Frontiers
The IEEE report focuses on cryptography, yet that’s not the full picture when it comes to security.
Two other security aspects of blockchains that have received increasingly more are formally verified smart contracts and Trusted Execution Environments (TEE’s).
Smart contracts written in formally verified languages have the benefit that it is possible to calculate mathematically with 100% certainty what the result of a smart contract will provide for a given input.
This makes them more safe to use then their ‘non-deterministic’ counterparts because there can be certainty around what they will do. Outside of blockchain, formally verified languages are commonly used for critical systems such as nuclear power plants. However, at the same time this style of programming language can impose restrictions on what blockchain can do that can make them unsuitable for certain types of work.
It will be interesting to see if NIST forms a view on formally verified languages in the next few years.
A Trusted Execution Environment, on the other hand, is a rapidly maturing security technology which provides a way for code to be run in a secure and confidential manner even if the computer that it is running on is not secure. It also provides a safe place for storing encryption keys and other sensitive data.
It’s an area of the market which has seen big investments by chip manufacturers, cloud providers and blockchain application providers alike in the last few years. Intel INTC and AMD have created CPUs that support this type of computing, which is then offered through cloud vendors such as Microsoft MSFT Azure and IBM IBM’s Data Cloud. Microsoft recently announced their Confidential Computing Framework that provides the building blocks for integrating blockchains that use confidential computing. R3 has also recently announced a beta program for its confidential computing initiative named conclave.
There still remains some controversy as to how secure these environments are as the CPU chip manufacturers hold part of the security puzzle and therefore require trust in the chipmaker.
Blockchain In The Federal Government Already
While the assessment from the IEEE may sound like a bit of a theoretical exercise, it is worth remembering that the U.S. federal government has already implemented blockchain and as such is a world leader in the space; the department of Health And Human services, a branch of the federal government, has received “Authorization To Proceed” with the use of a new procurement focused blockchain (HHS Accelerate) that aims to save the government over $30m in procurement costs over the next five years.
In an interesting update, since posting this article, HHS has confirmed that they used Hyperledger Fabric for HHS Accelerate. So could this be a case of ‘“rules are for the guidance of the wise but the obedience of fools?’.
The federal government, at least seems, is serious about blockchain.