Blog

By Dan Anderson, Intel 

Hyperledger Sawtooth is a permissioned enterprise blockchain platform that is built in a modular fashion. The Sawtooth blockchain (essentially an electronic ledger) is immutable (transactions cannot be deleted or modified), highly available, transparent (all transactions are visible), distributed and has several security mechanisms, which I describe below.

By the way, for the record, there is no Sawtoothium, Sawtooth Coin, Sawbucks, STC, or anything like that previously built into the Sawtooth platform. Sawtooth has no digital currency and has no miners. Of course, a Sawtooth application can create and manage digital currency or other assets.

Security for an enterprise blockchain is important because it’s shared among frenemies—mutually distrusting organizations that need to work together. This is the first of three articles on Sawtooth Security:

• Part 1: Sawtooth Consensus Algorithms
• Part 2: Sawtooth Node and Transaction Processor Security
• Part 3: Client Application Security and Network Security

Consensus Algorithms

In Sawtooth, a major task of a consensus algorithm is leader selection, deciding which competing peer node can publish a new block on the blockchain. What are the security implications of a consensus algorithm? A secure consensus algorithm is important to prevent a “rogue” node (bad actor) from “gaming” the system. A bad actor can publish transactions favorable to it or a third-party before or in lieu of transactions from other nodes. In several applications, just having better timing is a big advantage—consider the stock market or real estate or any market with scarce goods at a fluctuating price.

Prelude: Byzantine Generals Problem

Before discussing consensus algorithm details, it’s good to review the Byzantine Generals Problem. The problem was first proposed in 1982 by Leslie Lamport et al. Basically you have n generals deciding whether to attack or retreat. But some generals may be malicious traitors (bad actors) and send the wrong advice. The goal is to agree on a common plan (attack or retreat) that is not influenced by the malicious generals. The classical solution to the Byzantine Generals Problem requires (3m + 1) total generals to safeguard against the votes of m malicious generals.

Byzantine Fault Tolerance (BFT) v. Crash Fault Tolerance (CFT)

In general (not a pun),  Byzantine Fault Tolerant (BFT) solutions can withstand malicious (or bad actors) among the nodes. Crash Fault Tolerant (CFT) solutions assume no node is malicious—that is, there are no bad actors. A node can crash or disappear from the network, but it does not misbehave. CFT solutions are usually less expensive than BFT ones.

Types of Consensus Algorithms

A Consensus Algorithm decides which of several competing block candidates from multiple nodes will be added to the blockchain. Consensus algorithms come in two classes: Nakamoto lottery-like consensus and Classical or voting-like consensus

Nakamoto Consensus

Nakamoto-style consensus algorithms all use some kind of lottery-like system to pick a winner. It includes Proof of Work (PoW), the consensus algorithm used in Bitcoin. PoW selects a winner by solving the cryptographic puzzle of finding the most leading 0s in a SHA-256 result. Unfortunately PoW is wasteful—it’s estimated to use about ~2.5 gigawatts/year. As a comparison, Ireland consumes ~3.1 gigawatts/year.

Sawtooth’s Proof of Elapsed Time (PoET) is also a Nakamoto-style consensus algorithm. PoET selects as the winner the node with the first expired randomly generated wait time. More on PoET later.

Another Nakamoto-style consensus algorithm, still in the experimental stage, is Proof of Stake (PoS), where the winner has the most of something (wealth, age, etc.)

All Nakamoto-style consensus algorithms can fork—that is have two competing blockchains with different blocks appended to the end. The forking consensus algorithms have various resolution methods to solve forking.

Classical Consensus

Classical Consensus uses an agreement or voting mechanism to select a leader. Examples include Practical Byzantine Fault Tolerance (PBFT) or Raft.

PBFT uses a state machine and selects a leader by block election. PBFT does not fork. PBFT uses a three-phase, network-intensive algorithm (n^2 messages), so is not scalable to large networks.

Raft consensus elects a leader for an arbitrary term of time. If the leader times out, the leader is replaced. Raft is both fast and CFT, but it is not BFT. Also Raft does not fork.

Sawtooth’s Pluggable Consensus

Sawtooth supports “pluggable” consensus algorithms—that is it is configurable. Not only is the consensus configurable at blockchain genesis (block 0), but the consensus algorithm can be changed at any point after after blockchain creation with an in-chain setting, sawtooth.consensus.algorithm.

Consensus algorithms supported by Sawtooth are:

• DevMode – a simple consensus algorithm for development use only
• PoET CFT – PoET runs without SGX hardware, which is CFT
• PoET SGX – PoET runs with SGX hardware, which is BFT
• RAFT – uses an elected leader and it is faster than PoET. It is only CFT and not BFT

Other consensus algorithms are in the works, such as PBFT. The Sawtooth community encourages contributions of other consensus algorithms by third parties. There are many consensus algorithms, each with advantages and disadvantages, and consensus algorithms in general is an active area of research!

Proof of Elapsed Time (PoET) Consensus

Proof of Elapsed Time (PoET) consensus is one of the consensus algorithms available with Sawtooth. PoET comes in two flavors, both for production use:

• PoET SGX runs with SGX hardware. It is BFT
• PoET CFT (also called PoET Simulator Mode) runs without SGX hardware. It is only CFT

Prelude: Intel® Software Guard Extensions (SGX) Overview

But before we can discuss PoET, we need to review SGX. A TEE (Trusted Execution Environment) runs code in a protected region of memory, called an enclave. Intel’s implementation of a TEE is Software Guard Extensions (SGX), which was first released in 2015. A SGX enclave can be thought of as a “reverse sandbox” or “fort.” The enclave prevents the rest of the system from accessing protected code or data residing inside the enclave. This is implemented with encryption.

Contrast a SGX enclave with a more traditional “sandbox” where the code in the sandbox is prevented from accessing code or data outside the sandbox. A SGX enclave is the reverse—it prevents malicious actors (including rogue operating system or application code) from access inside the enclave. This allows the enclave to safely execute in a hostile outside environment. SGX does not have to trust the OS or other software on a host.

Another important SGX function is its ability to “attest” to code that’s in the enclave—it provides high confidence that code is authentic and not tampered with before it’s been loaded.

SGX allows multiple enclaves on the same host. Separate enclaves would have separate functions and run independent of each other. The code and data should be as small as possible. Limiting enclave size reduces exposure to possible vulnerabilities from outside the enclave. So, for example, hosting a programming language interpreter would be inappropriate for an enclave.

Proof of Elapsed Time – Software Guard Extensions (PoET SGX)

Proof of Elapsed Time (PoET) consensus, as mentioned above, is a Nakamoto-style consensus algorithm. That is, it uses a lottery-based mechanism. Each node generates a random wait time value in a secure SGX enclave, then waits that many seconds. The node with the timer that expires first wins and can add its proposed block to the blockchain. The random wait time value is signed in the enclave, and all other nodes verify the timer signature.

The PoET Timer is implemented to run within a SGX enclave. The SGX enclave securely generates a tamper-proof random wait time value. The enclave then signs a certificate with the wait time value. Outside the enclave, each node waits the required amount of time. After the timer expires, the SGX attestation is sent to the other network nodes. The peer nodes verify the wait time signature generated by the winning node. The winning node gets to publish its proposed block onto the blockchain.

PoET has multiple defense-in-depth tests to prevent cheating by a rogue node. They are:

• Z Test confirms that a block-claiming validator is not winning too frequently
• C Test requires that a new node must wait C blocks after admission before its blocks are accepted. This is to prevent gaming identities and some obscure corner scenario
• K Test restricts a node to publishing at most K blocks before its peers require the node to recertify itself

Proof of Elapsed Time – Crash Fault Tolerant (PoET CFT)

PoET is also available without SGX. It uses the same algorithm and shares the same code as PoET SGX, except that the enclave module is simulated. Because the SGX protections are simulated, PoET CFT is not BFT. Keep in mind that other consensus algorithms, such as Raft or Kafka, are also CFT and not BFT. No special hardware is required for PoET CFT, and it is still a stable algorithm.

Conclusion

This concludes part one of my blog on Hyperledger Sawtooth Security, where I discussed consensus algorithms. As you can see, the choice of consensus algorithm is a trade-off between performance, security (resistance to bad actors), and scalability (number of network nodes). Part two will continue with a discussion on Sawtooth node and transaction processor security.

Have you always wanted to know how to deploy Hyperledger Fabric on Kubernetes? Then we have something just for you!

We recently hosted a webinar about deploying Hyperledger Fabric on Kubernetes.

Deploying a multi-component system like Hyperledger Fabric to production is challenging, and the event was aimed at developers and DevOps specialists with limited knowledge in the area.

The webinar contained four sections. First, the presenters introduced Hyperledger Fabric. They then covered Kubernetes, a platform for deploying micro-services. In the third and main section, the presenters showed step-by-step how to deploy the Fabric Certificate Authority, the Fabric Orderer and Fabric Peers. Each basic concept (like Certificate Authority or Helm chart) was explained. Finally, the presenters shared resources for further learning and involvement.

Alejandro (Sasha) Vicente Grabovetsky, CTO and Chief Data Scientist at AID:Tech, and Nicola Paoli, Lead Blockchain Engineer, led the webinar. AID:Tech is an award-winning company that focuses on the delivery of digital entitlements, including welfare, aid, remittance and donations using Blockchain & Digital Identity.

This webinar provides a helpful, hands-on guide to deploying Hyperledger Fabric on Kubernetes. Watch the replay here, or download the webinar slides and other resources on the same page. You can also head straight to the Github repository set up for the webinar.

Be sure to stay tuned for Part II of this post, where we will actually walk through how to deploy Hyperledger Fabric on Kubernetes. Also, make sure you do not miss any upcoming webinars from Hyperledger by signing up here!

The use of blockchains in business IT is still emerging as companies continue to explore new ways to use the technology. Its strength as a platform to build new generations of transactional applications that will allow users to establish trust and maintain high security for their data and processes is one of its greatest promises and attractions.

To help make blockchains more approachable, here are six best practices from Hyperledger that can be expanded and incorporated by businesses as they dive into blockchains to help their companies deal with their data, security and business processes in the future.

1. Secure today does not mean secure tomorrow

When people hear about blockchain, one of the things they learn about is that it is secure and cryptographically protected. With that information, they then often think they shouldn’t have concerns about using blockchain along with personally identifiable information (PII). The problem is that such an assumption fails to consider the future because as soon as hackers and other bad actors eventually break the cryptographic algorithms that protect such blockchain data today, then all that data will become a treasure trove for criminals. Regardless, developing technologies such as quantum computing could one day make successful attacks on the security of cryptographic keys possible.

So, when it comes to security, even with secure systems like blockchain, things are only as secure as they are today. Tomorrow there may be mechanisms to crack those cryptographic keys, allowing attackers to see all the information that’s put onto a blockchain. With that in mind, a critical best practice is that users should never put PII on their blockchains. In today’s use of blockchain, this best practice is table stakes.

2. Never store large files on a blockchain

Blockchains work by using large numbers of computers that are basically replicating data. So, when data is stored on the blockchain, it gets sent to every other node or peer on the blockchain network. When that happens, storage and compute costs can go up exponentially. To avoid those kinds of added costs, other means of storing and replicating that data should be used, including options such as the Amazon’s Simple Storage System (AWS S3), Google Cloud Platform’s Filestore or other cloud networks. That way, when users are storing big files, they are not paying extra to store, transfer and replicate multiple copies of the same data.

Instead, when using a blockchain, users can store a pointer or a link to a file but keep the actual data on whatever cloud platform they are using. They can also include a hash which notes the content of the file when it is stored, which can then be checked when the file is retrieved to see if the contents of that file have changed by checking it with the same hash algorithm. If it is the same, that tells a user that it’s unchanged and that somebody hasn’t gone in and changed its contents.

3. If you don’t want your data to be public, use a permissioned blockchain

Not all blockchains are public, where anybody has access to the information and can add transactions and read the data that’s in it. When enterprises want to keep things private, that’s where permissioned blockchains come in – data can be stored, accessed and used only between the partners who need to have access. That’s the main reason such permissioned blockchains exist. While things like Bitcoin and Ethereum are public blockchains, the Hyperledger projects are mostly permissioned blockchains. And that’s exactly why they are suitable for business. If your data must remain private, then use a permissioned blockchain. Some people call them private blockchains or consortium blockchains, but those normally fall into the permissioned blockchain space.

4. Create a governance structure for the blockchain

With blockchains, the challenges aren’t technical. Instead, the challenges involve the governance model that is chosen. To keep things working smoothly, it’s best to define the governance structure upfront and even before you dive into blockchain. For example, be sure to decide things like how new users or organizations will be added to a blockchain network, as well as how to determine if a user or organization should be cut out of the network. To protect the blockchain, the data and the rest, be sure to include a mechanism to deal with and remove bad actors who were previously allowed into the network. The governance structure can also address procedures for many other possible situations, as well as how to cope with the politics of the user group. Just remember, these things are still evolving, so those governance procedures will likely change over time. You can learn more about governance and how to manage it in blockchain networks via this webinar we did recently with MonetaGo.

5. Decide on performance and scalability requirements

Different tasks may require different blockchains. As a best practice, architects must understand the requirements for their specific use cases and ensure that their blockchains meet those requirements, just like they would evaluate for any other technology. Certain technologies fit better with specific requirements, so architects must decide on their trade-offs. Are they okay giving up scalability for performance or are they okay giving up the performance to get needed scalability? Those are the kinds of decisions that need to be made early on with each deployment and use case. With the different Hyperledger frameworks, enterprises can set up their own blockchain networks as needed. Enterprises might have multiple blockchains, one based on performance, one based on scalability, allowing them to hone-in on what the need.

6. Analyze blockchain business cases early

To ensure success for the project, says Jesse Chenard, the CEO of finance start-up MonetaGo, IT leaders should ask themselves lots of detailed questions early in the process about their goals for a blockchain initiative.

“You really need to analyze the business case and go through a checklist,” says Chenard. “Do multiple people need access to the data? Do you need an audit trail? Do you actually even need a blockchain? Does it make sense for us?” For some projects, the use of a database can be the right choice, according to Chenard.

Enterprises should approach the project by designing and building a strategy that will help the project reach its goals, and not just aimlessly look to create a blockchain just to dive into the latest technology, he says. At the same time, enterprise IT leaders shouldn’t try to plan ahead for every feature and capability for their blockchains because some will become more apparent later and can be added as the project proceeds, says Chenard.

Blockchain can be a great choice for projects that rely on security, controlled access, accountability, transparency and efficiency in a wide range of fields, from finance to banking, supply chains, manufacturing and more. Having well laid plans, goals and best practices can all help enterprise IT leaders explore the growing blockchain ecosystem as they work to capture its strengths for their businesses.

Guest post: Rohas Nagpal, Primechain Technologies

1. Introduction

Financial and capital markets use the KYC (Know Your Customer) system to identify “bad” customers and minimize money laundering, tax evasion, and terrorism financing. Efforts to prevent money laundering and the financing of terrorism are costing the financial sector billions of dollars. Banks are also exposed to huge penalties for failure to follow KYC guidelines. Costs aside, KYC can delay transactions and lead to duplication of effort between banks.

Blockchain-eKYC is a permissioned Hyperledger Sawtooth blockchain for sharing corporate KYC records amongst banks and other financial institutions.

The records are stored in the blockchain in an encrypted form and can only be viewed by entities that have been “whitelisted” by the issuer entity. This ensures data privacy and confidentiality while at the same time ensuring that records are shared only between entities that trust each other.

Blockchain-eKYC is maintained by Rahul Tiwari, Blockchain Developer, Primechain Technologies Pvt. Ltd.

The source code of Blockchain-eKYC is available on GitHub at:

https://github.com/Primechain/blockchain-ekyc-sawtooth

Primary benefits

1. Removes duplication of effort, automates processes and reduces compliance errors.
2. Enables the distribution of encrypted updates to client information in real time.
3. Provides the historical record of all compliance activities undertaken for each customer.
4. Provides the historical record of all documents pertaining to each customer.
5. Establishes records that can be used as evidence to prove to regulators that the bank has complied with all relevant regulations.
6. Enables identification of entities attempting to create fraudulent histories.
7. Enables data and records to be analyzed to spot criminal activities.

2. Uploading records

Records can be uploaded in any format (doc, pdf, jpg etc.) up to a maximum of 10 MB per record. These records are automatically encrypted using AES symmetric encryption algorithm and the decryption keys are automatically stored in the exclusive web application of the uploading entity.

When a new record is uploaded to the blockchain, the following information must be provided:

1. Corporate Identity Number (CIN) of the entity to which this document relates – this information is stored in the blockchain in plain text / un-encrypted form and cannot be changed.
2. Document category – this information is stored in the blockchain in plain text / un-encrypted form and cannot be changed.
3. Document type – this information is stored in the blockchain in plain text / un-encrypted form and cannot be changed.
4. A brief description of the document – this information is stored in the blockchain in plain text / un-encrypted form and cannot be changed.
5. The document – this can be in pdf, word, excel, image or other format and is stored in the blockchain in AES-encrypted form and cannot be changed. The decryption key is stored in the relevant bank’s dedicated database and does NOT go into the blockchain.

When the above information is provided, this is what happens:

1. Hash of the uploaded file is calculated.
2. The file is digitally signed using the private key of the uploader bank.
3. The file is encrypted using AES symmetric encryption.
4. The encrypted data is converted into hexadecimal.
5. The non-encrypted data is converted into hexadecimal.
6. Hexadecimal content is uploaded to the blockchain.

Sample output:

  {file_hash: 84a9ceb1ee3a8b0dc509dded516483d1c4d976c13260ffcedf508cfc32b52fbe
     file_txid: 2e770002051216052b3fdb94bf78d43a8420878063f9c3411b223b38a60da81d
     data_txid: 85fc7ff1320dd43d28d459520fe5b06ebe7ad89346a819b31a5a61b01e7aac74
     signature: IBJNCjmclS2d3jd/jfepfJHFeevLdfYiN22V0T2VuetiBDMH05vziUWhUUH/tgn5HXdpSXjMFISOqFl7JPU8Tt8=
     secrect_key: ZOwWyWHiOvLGgEr4sTssiir6qUX0g3u0
     initialisation_vector: FAaZB6MuHIuX}

3. Transaction Processor and State

This section uses the following terminology:

• Transaction Processor – this is the business logic / smart contracts layer.
• Validator Process – this is the Global State Store layer.
• Client Application (User) – this implies a user of the solution; the user’s public key executes the transactions.

The Transaction Processor of the eKYC application is written in Java. It contains all the business logic of the application. Hyperledger Sawtooth stores data within a Merkle Tree. Data is stored in leaf nodes and each node is accessed using an addressing scheme that is composed of 35 bytes, represented as 70 hex characters.

Using the Corporate Identity Number, or CIN, provided by the user while uploading, a 70 characters (35 bytes) address is created for uploading a record to the blockchain. To understand the address creation and namespace design process, see the documentation regarding Address and Namespace Design.

Below is the address creation logic in the application:

Note:

• uniqueValue is the type of data (can be any value)
• kycAddress is the CIN of the uploaded document.

The User can upload multiple files using the same CIN. However, state will return only the latest uploaded document. To get all the uploaded documents on the same address, business logic is written in Transaction Processor.

The else { part will do the uploading of multiple documents on the same address and fetching every uploaded document from the state.

4. Client Application

The client application uses REST API endpoints to upload (POST) and get (GET) documents on the Sawtooth blockchain platform. It is written in Nodejs. In case of uploading, few steps to be considered:

• Creating and encoding transactions having header, header signature, and payload.(Transaction payloads are composed of binary-encoded data that is opaque to the validator.)

• Creating BatchHeader, Batch, and encoding Batches.

• Submitting batches to the validator.

When getting uploaded data from blockchain, the following steps needs to be considered:

1. Creating the same address from the CIN given by User, using GET method to fetch the data stored on the particular address. As shown in  the following code snippet, updatedAddress is created by getting user input either from User (search using CIN in the network) or from the private database of the user (Records uploaded by the user). Similarly, splitStringArray splits the data returned from a particular address because of the transaction logic written in the Transaction Processor to upload multiple documents on the same address while updating state with the list of all the uploaded data (not only the current payload).

2. The client side logic is then written to convert the splitStringArray by decoding it to the required format and giving User an option to download the same in the form of a file.

5. Installation and setup

Please refer to the guide here: https://github.com/Primechain/blockchain-ekyc-sawtooth/blob/master/setup.MD

6. Third party software and components

Third party software and components: bcryptjs, body-parser, connect-flash, cookie-parser, express, express-fileupload, express-handlebars, express-session, express-validator, mongodb, mongoose, multichain, passport, passport-local, sendgrid/mail.

7. License

Blockchain-eKYC is available under Apache License 2.0. This license does not extend to third party software and components.

Since its inception at the end of 2015, Hyperledger has grown from two projects to ten, and the adoption of the Hyperledger platforms and tools has spread across a wide range of industries. Even as Hyperledger has become a trusted name when it comes to using blockchain for the enterprise, there are still some misperceptions that we’d like to debunk once and for all.

Myth #1: Hyperledger is a vendor.

Reality: Hyperledger is not a vendor. It is a non-profit industry consortium with a membership-based model. Anyone can use the code, contribute, and even become a core maintainer on any of the projects, whether or not they work at member companies. We do have a growing subset of our member community that offer business blockchain products and services based on Hyperledger projects; you can check the 80+ organizations and offerings in the vendor directory.

Myth #2: Hyperledger is an IBM- and Intel-run shop.

Reality: Though a number of Hyperledger projects were originally contributed by IBM (Hyperledger Fabric, Hyperledger Composer, Hyperledger Cello, Hyperledger Explorer) and Intel (Hyperledger Sawtooth, Hyperledger Explorer), the diversity of the developers working on the projects grows every day. Over the lifetime of all 10 Hyperledger projects, there have been 729 unique code contributors, representing more than 150 organizations. The recent 1.2 release of Hyperledger Fabric featured contributions from 15 companies, including Accenture, BBVA, Oracle, and Blocledger; 22% of the commits came from non-IBM sources. In the Hyperledger Sawtooth project, Bitwise has eclipsed Intel in the maintainer count. We are grateful for the continued resources and support that IBM and Intel provide, and encourage other companies to follow their lead, so that Hyperledger remains a healthy, multi-stakeholder community.

Myth #3: Hyperledger doesn’t support interoperability.

Reality: Hyperledger Quilt, one of the five tools in the Hyperledger greenhouse, offers a way of guaranteeing transactional coherence across two ledgers. And that’s just the start of what Hyperledger can do for interoperability.

An early example of this was the integration between the Hyperledger Sawtooth and Hyperledger Burrow projects last year. As a result of that integration, simple EVM smart contracts can be deployed to Hyperledger Sawtooth using the “Seth” (Sawtooth Ethereum) Transaction Family.

More recently, the  Hyperledger Fabric community began working to create a bridge to the Ethereum community so that developers can write EVM smart contracts on Fabric. The hope is that our community will continue to tighten integration and interoperability across Hyperledger projects and beyond, creating a greater number of options for developers. We hope that even more developers can start to think out of the box, connecting blockchains, and doing it securely. The problem of working with more than one technology stack is no longer a technical one.

Our philosophy has always been that you can write one blockchain that talks to multiple other blockchains at the same time. They’re not hermetically sealed.

Myth #4: Hyperledger isn’t focused on scalability and privacy.

Reality: Hyperledger is working on multiple fronts to improve scalability and privacy. The Performance and Scale Working Group is collaborating on defining key metrics for scalability in blockchain technology. Hyperledger Fabric already has a scalability feature called ordering nodes, which lets you focus a subset of your network on the performance-critical part of it in order to improve performance.

When it comes to personal data, Hyperledger Indy upholds the standards mandated by GDPR. Hyperledger Fabric has support for private channels, which is one of the techniques for providing confidentiality between parties with their transactions on the blockchain.

At the same time, our Hyperledger Architecture Working Group has a working draft of an evaluation of the different Hyperledger projects’ approaches to privacy and confidentiality.

Myth #5: Hyperledger blockchains are one network per application.

Reality: Our vision is that there can be multiple, different applications for each network. The food trust network that is being developed with Walmart, for example, could be applied to trace fish, packaged greens, and consumer products, all at the same time. Plus, we are eager to see the interesting applications that can be built on top of that traceability.

The Hyperledger community keeps growing: We’re up to 277 member organizations, including new members FedEx and Honeywell. While that should mean greater awareness of who we are and what we do, we also want to continue to answer your questions. Are there other myths you have heard or seen? Not sure if something is true or not about Hyperledger and blockchain in general? Feel free to share with us on Twitter @Hyperledger.

We hope you join us in the effort by contributing to Hyperledger projects. You can plug into the Hyperledger community at github, Rocket.Chat the wiki or our mailing list. As always, you can or email us with any questions: info@hyperledger.org.