Ethereum, Fabric, Corda, And Multichain. Only One Is Government Ready – New Report

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.

American flag waving with the Capitol Hill

The Federal Government Has Stringent Rules Around Adoption Of New Technology


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.

NIST Event

UNITED STATES – FEBRUARY 08: From left, Sens. Ben Cardin, D-Md., Barbara Mikulski, D-Md., and … [+] Commerce Secretary Penny Pritzker attend a ribbon-cutting event for the newly expanded National Cybersecurity Center of Excellence (NCCoE) at the National Institutes of Standards and Technology (NIST) in Rockville, Md., February 08, 2016. (Photo By Tom Williams/CQ Roll Call)

CQ-Roll Call, Inc via Getty Images

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.

Comparison of four protocols

Comparison of four protocols

Source: Blockchain Compliance With Federal Cryptographic Information-Processing Standards James P. Howard II | Johns Hopkins Applied Physics Laboratory Maria E. Vachino | Easy Dynamics Corp.

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.

Corda Logo

Corda Holds The Lead, For Now At Least

Credit: R3

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.


Web Attack: Formjacking Website 59 AND

I need a solution

Today we’ve been flooded with this alert from dozens of clients:

09:08:20,Critical,xxxx,SHA-256: ,MD-5: ,[SID: 31515] Web Attack: Formjacking Website 59 attack blocked. Traffic has been blocked for this application: C:Program Files (x86)Internet Exploreriexplore.exe,Local:,Local: 000000000000,Remote: ,Remote:,Remote: 000000000000,Inbound,OTHERS,,Begin: 2019-12-05 09:08:22,End: 2019-12-05 09:08:22,Occurrences: 1,Application: C:/Program Files (x86)/Internet Explorer/iexplore.exe,Location: On Network,User: xxxx,Domain: xxxx,Local Port 0,Remote Port 0,CIDS Signature ID: 31515,CIDS Signature string: Web Attack: Formjacking Website 59,CIDS Signature SubID: 0,Intrusion URL:,Intrusion Payload URL:

This appears to be a legit company that provides bot protection ( and the NY Times is one of them.  So in each case the user has visited NY time shortly before this alert.  We’ve had traffic to this site for a long time so I’m guessing this is a new signature that isn’t working right but we’re not sure at this point. 

The js is heavily obfuscated but they do have a nice heading:

    pre style = “word-wrap: break-word; white-space: pre-wrap;” > /** DataDome is a cybersecurity solution to detect bot activity (version 3.19.4) */

    var _0x55aa = [‘x63x33x42x73x61x58x51x3d’, ‘x59x32x46x73x62x46x42x6fx59x57x35x30x62x32x30x3d’, ‘x58x33x42x6fx59x57x35x30x62x32x30x3d’, ‘x59x6ex4ax76x64x33x4ex6cx63x6bx78x68x62x6dx64x31x59x57x64x6c’, ‘x5ax47x52x66x61x77x3dx3d’, ‘x63x47x46x79x63x32x55x3d’, ‘x64x58x4ax73’, (function(_0x5e829e, _0xeab3b6) {

Anyone else seen this or know if it’s a false positive?  One weakness in the symantec threat database is that it doesn’t show the date the signature was created or last updated (  Tenable does this with Snort sigs and it helps troubleshooting.




  • No Related Posts

SEP SupportTool False Positive Detection as a Virus

I need a solution

Hello I don’t know if this is the right place to post this but our Symantec Endpoint Protection just flagged SEP_SupportTool.exe as potiential malware and deleted the file. The SHA-256 HASH of the file is A87D1A8EFCD1B8628861E949ED9E8774928E72482CEC74483F70400A8C8E94CC 

I was wondering if anyone else was getting hit by these notifications and also can someone verify that this file is from Symantic?



  • No Related Posts

Avamar 7.5: PuTTY releases older than v0.63 fail to connect with “Server unexpectedly closed network connection” due to new MAC entries in the SSH server configuration file

Article Number: 504576 Article Version: 6 Article Type: Break Fix

Avamar Server,Avamar Server 7.5.0-183

In cryptography, a message authentication code (MAC), sometimes known as a tag, is a short piece of information used to authenticate a message—in other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed. The MAC value protects both a message’s data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content.

The sshd_config for Avamar 7.5.x or greater version supports the following MACs:

grep MAC /etc/ssh/sshd_config

MACs,hmac-sha2-512,,hmac-sha2-256,,,,hmac-ripemd160PermitEmptyPasswords no
After a fresh install when attempting to login to the Avamar grid using the 3rd party application PuTTY, following error is seen:

/var/log/messages can show the following error when logged via a console such as lights out port (RMC for Gen4t, RMM for Gen4s, vSphere Console for AVEs etc):

Oct 30 12:27:19 testavamar sshd[6087]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5 server,hmac-sha2-512,,hmac-sha2-256,,,,hmac-ripemd160

PuTTY releases less than version 0.63 doesn’t support these MACs

Recent install of a 7.5.x system

MAC entries were added to the sshd config file (/etc/ssh/sshd_config) on the Avamar Server

Download a PuTTY version that is greater than or equal to 0.63 and then ssh into the Avamar Server.

Note: As of September 28, 2017, the latest version of PuTTy is 0.70


  • No Related Posts