leaf

Over the past two years, ransomware has attracted significant media coverage due to the emergence of WannaCry, NotPetya, and Locky. In May 2017, WannaCry ransomware rapidly spread across multiple systems worldwide. It attacked several well-known organizations, including the UK's National Health Service, Spain's Telefonica, French car manufacturer Renault, American logistics company FedEx, Japanese company Hitachi, and many other large enterprises.

The authors of ransomware host services on the dark web, allowing any buyer to create and improve malware.

The dark web is a part of the internet that cannot be accessed through regular search engines and requires a special type of anonymous browser, Tor, to log in. In other words, the dark web contains unindexed data that regular search engines cannot access. The Tor browser essentially routes user information through a series of proxy servers, making user identities unidentifiable and untraceable. The dark web looks similar to regular websites, but there are some differences in naming structure. The dark web does not use top-level domains (TLDs) like .com, .net, or .co. Instead, they only use domain names that end with .onion.

1. Monetization of Hacking

According to cybersecurity business reports, ransomware losses are expected to reach $11.5 billion by 2019. There are several driving factors globally that contribute to the continued growth of the ransomware business. To achieve quicker profits, cybercriminals no longer compile malware independently but instead utilize ransomware as a service (RaaS), which can be obtained on dark web markets.

These markets not only allow criminal experts to spend less effort creating ransomware but also enable non-technical criminals or programmers to use scripts for ransomware operations.

Attackers use preconfigured timers to generate ransomware programs, and if the ransom is not paid before the deadline, the data will be destroyed. Attackers also share a payment program that primarily conducts transactions through Bitcoin wallets (as digital cryptocurrency wallets provide anonymity).

2. WannaCry

The WannaCry attack was the largest ransomware attack event that occurred on May 12, 2017. WannaCry exploited a vulnerability in the Windows operating system, which was first discovered by the NSA and then made public by the Shadow Brokers. It aimed to exploit vulnerabilities in Windows SMBv1 and SMBv2 to spread laterally across networks. As of May 24, 2017, the ransomware had infected over 200,000 computer systems in 150 countries and regions.

3. NotPetya

NotPetya is another style of ransomware attack that was launched in June 2017. NotPetya ransomware is notably similar to the Petya virus in several ways—it encrypts files and displays a window requesting payment in Bitcoin to restore the files. The initial infection vector was through a backend program of M.E.Doc. After infecting systems via M.E.Doc software, NotPetya spread across networks using tools like EternalBlue and EternalRomance. It also attempted to use a tool called Mimi Katz to search for administrative credentials on infected computers.

4. SimpleLocker

SimpleLocker was the first ransomware attack that did not infect any computer systems but targeted several smart mobile devices. The first target mobile system chosen by hackers was Android, and the source of this ransomware was traced back to Eastern Europe. The Trojan's attack targeted SD cards inserted into tablets and phones, automatically scraping the entire system for certain files and then demanding cash for decrypting the corresponding data. The virus entered devices through the Google Play Store. Once installed, the virus would scan affected devices for various file types and encrypt them using the AES encryption algorithm, changing the file extension to .enc. It also collected various other information from the respective devices, such as IMEI numbers, device models, and manufacturers, and sent it to servers controlled remotely by hackers. The latest versions of this Trojan software could even access device cameras and display photos of victims to intimidate them into paying the ransom. This type of Trojan software remains a lurking threat today.

5. TeslaCrypt

A new threat called TeslaCrypt emerged a year after CryptoLocker. Initially, many believed it was another form of CryptoLocker, but it was later given a new name—TeslaCrypt. This ransomware targeted a different group of people—hardcore gamers. TeslaCrypt targeted and affected auxiliary files associated with video games. These auxiliary files included saved game files, maps, and any downloadable content related to the games. What made this ransomware unique was that the software authors continuously improved the Trojan and fixed all vulnerabilities while the attacks were ongoing.

6. CryptoLocker

CryptoLocker is a large-scale ransomware that was first released on the internet on September 5, 2013, spreading through email attachments and the Gameover Zeus botnet. It affects devices running Microsoft Windows and continues to spread through malicious email attachments, using the RSA encryption algorithm to encrypt certain types of files stored on users' local and network drives. CryptoLocker was removed in late May 2014 through the Tovar operation, which crippled the Gameover Zeus botnet. Reports indicated that CryptoLocker successfully extorted over $3 million from victims.

7. PC Cyborg

In 1989, a Trojan called PC Cyborg emerged, capable of hiding folders and encrypting file names on the C drive. This led victims to pay $189 to the PC Cyborg company.

A widely accepted approach initially proposed by Forrester is data-centric, which is used to achieve continuous verification of all data and resources. It was originally designed to address the issues of flat networks and later used to help threat actors roam through internal networks undetected, stealing sensitive and confidential information. This approach also allows security professionals to regain control over networks and applications. Next, we begin to explore the zero-trust methodology:

1. Identify and classify sensitive data: To protect your data, you first need to look at and understand it. If you are unaware of your sensitive data, the situation may worsen after an infection. Once sensitive information is identified, it is necessary to classify it.

2. Map data flow diagrams: It is important to have a high-level understanding of application flows within the network. Additionally, it is beneficial to collaborate with stakeholders, including network teams, application teams, and security engineers, to prepare the final data flow using existing models.

3. Establish network architecture: The design of zero trust demonstrates the communication flow between multiple networks and explains how users should access external data. In this case, an organization can leverage physical and virtual switch configurations to confirm micro-boundaries.

4. Build a policy foundation: A key point of this approach is that security experts should restrict user access based on need-to-know principles and implement effective access control. In addition to understanding IP header fields, security teams also need to understand user identities and application behaviors.

5. Continuous monitoring: You should collect and inspect logs across the entire network and applications in real-time, including traffic from external networks as well as from private networks. The handling of internal traffic should be the same as that of external traffic.

Visit https://www.forrester.com/search?N=21061+10001sort=3everything=truesource=browse to learn about the zero-trust approach.

· Visit https://hbr.org/2017/01/the-truth-about-blockchain to learn about TCP/IP and blockchain.

In 2009, Satoshi Nakamoto published a white paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System," aimed at addressing challenges in the financial market. This white paper was dedicated to developing a platform that allows online payments from one party to another without going through a financial institution intermediary. One major problem that Bitcoin solves is double spending, which can prevent the double use of Bitcoin (a unique issue of digital currency is how to prevent users from reusing coins after spending them). Since Bitcoin is digital currency, it is not difficult to copy and publish digital data, leading to the double spending problem. A solution to prevent this situation emerged—that is, blockchain. However, Satoshi's original paper did not mention the term blockchain but instead referred to it in the comments of the Bitcoin source code in the form of a chain of blocks.

Blockchain is a decentralized database that ensures the security of all transaction records and records them in an additive manner. Due to its decentralized nature, blockchain has rapidly gained popularity across various industries. For an organization that cannot tolerate even a slight failure, a blockchain database makes sensitive information virtually impossible to be compromised by cybercriminals. Furthermore, blockchain is not managed solely by trusted administrators or developers; anyone who can be trusted or comes from known or unknown parties can manage it well. Below is a graphical representation of a blockchain network:

Every computer connected to the network needs to have blockchain node software and run applications targeting the blockchain ecosystem. Depending on usage, participation from these computers may be limited. For example, a blockchain-based banking chain ecosystem only allows bank nodes to run the client application of the banking chain.

The internet is a technology with a history of over 30 years, designed to share information through TCP/IP and the Open Systems Interconnection (OSI) model stack. Since the birth of the internet, every new technology, whether email, the web, or even e-commerce, has disrupted existing technologies. The internet is one of the most powerful technologies, capable of spreading ideas and creating virtual worlds.

TCP/IP is the first internet protocol suite that standardizes communication between similar networks. The OSI model was developed by the International Organization for Standardization (ISO) to provide a framework for standardized communication between systems without considering vendors, models, or technologies. Because client/server networks are inherently more reliable and stable, various organizations prefer two models based on client/server communication. Importantly, the data used by clients and how they use that data need to be better controlled. In a client/server model, clients manage their local resources, such as hardware and software components of workstations or any devices, while servers are functional systems that manage shared resources, such as hardware, network communication channels, and databases. In a peer-to-peer network, there is no central system to monitor, control, and execute commands. Although small businesses preferred this method in the past for internal needs, large organizations always avoided peer-to-peer networks due to the risk of losing control over their business operations and management.

However, in the process of connecting the entire world, there have been moments that have redefined innovation and provided a medium for the needs of every business. Blockchain, a peer-to-peer network composed of independent nodes, can share any type of value without any third-party involvement. The development of computers began with mainframes, and a decade later, the internet emerged. Cloud computing was defined by Professor Ramnath Chellappa in 1997, and Amazon launched its Elastic Compute Cloud (EC2) service in 2006. We are now in a new era where the way data is securely stored is constantly changing.

Everything done on the internet is accomplished through IP packets of the TCP/IP model. An IP packet is the smallest unit of data that can be sent over the internet, consisting of an IP header and a payload.

To send this information, it requires a source IP address and a destination IP address. Blocks are essential elements of this process, linked together to form a blockchain. A block consists of a block header and a block body. To send any type of value or complete any type of transaction, it adds its digital signature as a source identifier and a public key, similar to the destination identity in a peer-to-peer network.

Web applications are network-based applications widely used in the client/server model to serve users. However, decentralized applications (dApps) are applications that run on peer-to-peer computer networks.

Traditional web applications use CSS, HTML, and JavaScript to render front-end pages, retrieving data from databases through API calls. The front end of decentralized applications uses the exact same technologies to present pages, but it replaces API calls with smart contracts connected to the blockchain.

The operation of blockchain ledgers. To understand the general form of the system, it is essential to understand the multiple states of the chain and explore further.

1. Transaction preparation: At this stage, party A creates a transaction that includes the recipient's public address, source digital signature, and transaction information. Now, this transaction can be obtained by all nodes in the blockchain.

2. Transaction verification: Nodes in the blockchain work in a trustless model, where each node (a machine running blockchain client software) receives the transaction information and verifies the digital signature using party A's public key. After successful verification, this authenticated transaction information is placed in the ledger queue and waits until all nodes successfully verify the transaction.

3. Block generation: Transactions in the queue are placed together, and a node in the network creates a block. In the Bitcoin blockchain, when a Bitcoin node (also known as a miner node) creates a block by solving some complex mathematical problems, it receives a Bitcoin reward.

4. Block verification: After successfully generating a block, nodes in the network will process it for iterative verification, where most nodes need to reach a consensus mechanism. There are generally four commonly used consensus algorithms: Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT). Bitcoin uses PoW to reach consensus, while Ethereum uses PoS to achieve consensus. This mechanism plays a significant role in the financial sector, ensuring the security of the entire transaction operation.

5. Block linking: After successfully reaching consensus, the block is verified and added to the blockchain. The various states of the blockchain can be understood in the diagram below:

The world state data of Bitcoin is stored in the chainstate directory, managed using LevelDB, primarily storing all unspent transaction outputs and transaction metadata information to verify new incoming transactions and blocks, with appropriate compression applied during data storage. LevelDB is a persistent key-value database that utilizes the characteristic of sequential write performance being much larger than random writes, adopting an LSM-Tree structure to convert random writes on disk into sequential writes, greatly improving write speed. LSM splits the tree structure into a large and a small tree, with the smaller one residing in memory and the larger one persisted to disk. Write operations first operate on the tree in memory, and as the tree in memory continues to grow, it triggers a merge operation with the tree on disk, and the merge operation itself is only sequential writes. Bitcoin's LevelDB stores various data, with the most important being Coin data, stored in the following manner, where the Key is of CoinEntry type, consisting of three parts:

1 byte uppercase character "C" (DB_COIN), 32 bytes transaction ID value, and 4 bytes sequence number; Value is the serialized value of the Coin object.

Ethereum's World State Processing#

The world state is described through the globally unspent transaction outputs (UTXO) in the network, while Ethereum utilizes the concept of accounts to describe state information. The account state contains four attributes: nonce, balance, storageRoot, and codeHash. Ethereum manages account states using stateObject, with accounts uniquely identified by Address, and their information modified during the execution of related transactions. All account objects are inserted one by one into the Merkle-Patricia Trie (MPT) structure, forming the stateTrie. The Root field in the block header data structure stores the root value of the stateTrie, which is the hash value of the world state.

Blockchain technology is built on a set of existing technologies that have been widely applied across industries. Let's understand each component of blockchain that gives the entire system its inherently distributed, immutable, and trusted characteristics.

The consensus mechanism is a component of the blockchain system responsible for reaching a consensus protocol in a distributed environment. The openness and trustlessness of the blockchain environment are core features of blockchain; however, additional attention and strict processes are also essential. Because anyone can participate and submit information, it is crucial to assess the intentions of each participant and to adopt policies to avoid fraudulent attempts. This gives rise to consensus mechanisms, similar to signal processing, to ensure that all issues have been considered before actual communication begins. Below are four key methods for achieving consensus in blockchain:

· PoW: The founder of Bitcoin, Satoshi Nakamoto, invented a method to achieve consensus in the blockchain. In this type of consensus, fraud prevention is achieved by trusting those nodes that have completed the largest verifiable amount of computational work. Block creators, also known as miners in the world of digital currency, understand that having powerful computing capabilities increases their chances of successfully mining and receiving Bitcoin rewards. Each new transaction is broadcast to all nodes in the network, and each node continuously listens for all transactions. Nodes that want to earn rewards in the Bitcoin system are called miners; they do not just listen but also collect transactions. Miners must solve some complex mathematical problems using the PoW algorithm. The first miner to solve each problem receives a Bitcoin reward. Finally, the verified block is added to each miner's blockchain.

This mathematical problem involves applying a hash to a set of transactions and a nonce (a 32-bit random number) to achieve the desired hash output. If the output hash value is less than the target hash value, the miner wins the block and achieves consensus. When a miner wins a block, each block comes with some Bitcoin (BTC), and then the miner receives:

· January 2009 – November 2012: 50 BTC per block.

· November 2012 – July 2016: 25 BTC per block.

· July 2016 – February 2020: 12.5 BTC per block.

· February 20, 2020 – September 2023: 6.25 BTC per block.

· PoS: This is another method of achieving consensus and verifying transactions within the blockchain among nodes. Unlike PoW, PoS block generators do not choose based on their current stack. In this mechanism, blocks are not rewarded; miners in PoS are called validators. Ethereum uses PoS, and its purpose is to avoid environmental pressure associated with large power consumption. According to a report by digital economists in 2017, the entire Bitcoin network consumes more electricity in a year than the Republic of Ireland. Bitcoin uses the PoW mechanism and relies entirely on resource-rich miners, leading to greater power consumption. In the PoS mechanism, nodes must join a validation pool to be selected as validators. Casper, as Ethereum's PoS consensus protocol, is a hybrid consensus mechanism that extends the existing PoW mechanism, used for the last block in every hundred blocks of Ethereum. PoS is very suitable for platforms with a fixed coin supply, and it can be used for token distribution rather than investment.

· DPoS: This is another consensus protocol considered a faster and more efficient model. DPoS uses a democratic approach to solve consensus issues. Selecting block generators and confirming transactions in the network takes about one second. This way, you not only solve the consensus problem but also eliminate unnecessary regulatory interference.

· PBFT: Byzantine fault tolerance refers to a state where fault detection systems simultaneously exhibit faults and normal operations, displaying different patterns to different detectors. If some node members send inconsistent information about transactions to other nodes, it may lead to errors across the entire network. PBFT is a solution that protects the network from Byzantine faults.

Ethereum is one of the most mature blockchains, providing a method for platforms to offer custom blockchain systems. The purpose of Bitcoin is to disrupt the current payment systems and online banking with its consensus mechanism, while Ethereum is currently in the process of decentralizing existing computer systems, as it runs well on the client/server model.

Ethereum is a decentralized network capable of running applications in a distributed environment. The idea is simply to avoid complete reliance on a single entity to store and manage users' personal and business data. In current database systems, once data is stored online, clients cannot know how the data is stored, what security measures have been taken, or who can read the data. Ethereum provides a platform to build decentralized applications that connect directly to each stack holder or party for better transparency and zero dependency. Even though there are fundamental similarities between Bitcoin and Ethereum, they have significant differences in terms of use and functionality. With the use of Ethereum, any centralized service can be transformed into a decentralized service through its unique programming capabilities.

Ethereum primarily consists of three layers—Ethereum Virtual Machine (EVM), cryptocurrency, and gas (Ether and gas fees or energy).

Smart contracts are programs written by their creators to perform specific tasks. Although contracts can be coded on any blockchain version, Ethereum is the most popular because it offers scalable processing capabilities.

Ethereum allows developers to code for their smart contracts. Smart contracts can be used to:

· Simplify the claims settlement process by automatically triggering claims when specific events occur.

· Manage agreements between users.

· Store information about applications, such as health records and KYC information.

In Ethereum, each contract has an address to uniquely identify it. This address is calculated from the hash of the creator's address and the number of transactions executed.

When deploying a smart contract to a public blockchain environment, we obtain the address of the smart contract. Now, we can write code to interact with specific instances within the smart contract. Contracts have several standards, such as the ERC20 standard, and the methods required for implementation are also important.

Let’s try to create the first smart contract. We will use the Solidity language to write the smart contract. The programming language Solidity is similar to JavaScript. To start this process, we must first set up the environment using the Ganache package, which will be used to create a private blockchain. We need to access MyEtherWallet online, which can be found at https://github.com/kvhnuke/etherwallet/releases.

Once the package is installed, we access the link at https://remix.ethereum.org/ to enter the Ethereum IDE. The screenshot below shows the Ethereum IDE:

Remix is an online compiler for Solidity used to write smart contract code. This code is provided by the official for users to test. As we can see in the screenshot below, it has a variable and two functions. The variable c is an integer variable and is private, meaning that no one outside the contract can access it. The first function is plusbyone(), which changes the value of c by incrementing it, and the second function is getC(), which accesses c and returns its value to the caller of the function.

When the counter code is pasted into Remix, it will look like the screenshot below:

Now open Ganache, and we will see something like this. At the top of the screen, we can see it says RPC SERVER:

Now let’s try to access MyEtherWallet in the browser and see the result of doing so. In the upper right corner, you will see a dropdown menu showing that MyEtherWallet is connected to Ethereum. By default, it connects to Ethereum's main network. We must change this option by clicking the dropdown menu. Click the Add Custom Network/Node option, as shown in the screenshot below:

Now we can enter the RPC server information prepared by Ganache. We can name the node as shown below:

MyEtherWallet has connected to our self-hosted blockchain via Ganache. Upload the smart contract using MyEtherWallet. To do this, we will click on the Contract tab at the top of the MyEtherWallet navigation bar and select the Deploy Contract option:

As we can see, MyEtherWallet asks us to provide the bytecode of the contract.

To find it, we will return to the Remix IDE and click the Details button:

Now we will see a dialog box with information about the counter smart contract. To copy the bytecode, we will click the clipboard icon next to the BYTECODE section:

Now we will return to MyEtherWallet and paste the bytecode into the Byte Code text area:

Now we can scroll down and import an account address to upload the contract. By default, Ganache will show 5 addresses that can be used to interact with the private chain. We will return to Ganache and click the key icon to access any of the addresses:

Now we will see the private key associated with the account:

Now we must copy this private key and paste it into MyEtherWallet:

Now we can click the Unlock button, and MyEtherWallet will ask us if we want to sign the transaction and deploy the contract:

Finally, we will see a success prompt, as shown in the screenshot below:

After the transaction is successful, Ganache will increase its CURRENT BLOCK value, and the transaction count of the account we used to deploy the contract will also increase:

The smart contract is now uploaded to the blockchain. To interact with it by incrementing and decrementing the counter, we must return to MyEtherWallet and select the Interact with Contract option:

MyEtherWallet will now ask us to provide the address of the newly deployed smart contract and the application binary interface (ABI) of our contract. We can view the transaction logs as shown below:

As you can see, Ganache tells us the address used to deploy the contract. Let’s click on the transaction, copy the created contract address, and paste it into MyEtherWallet:

The screenshot below tells us that MyEtherWallet knows how to interact with our contract. We will return to Remix and click the clipboard icon next to the interface ABI to copy it:

Now we must return to MyEtherWallet, paste the ABI into its text box, and then click the Access button. We can interact with the contract by clicking the Select a function dropdown menu:

In our code, we set the initial value of the counter c to 0. To confirm that the smart contract is working correctly, we need to call the getC() function:

We can see the contract is returned, but we also did another function plusbyone(). Let’s call plusbyone() to test it. We will select the function dropdown menu again, choose plusbyone, and create a new transaction:

This just increased the value of c. Now, we can call getcount() again to confirm if the value has changed:

The EVM is a distributed runtime environment for building and managing smart contracts. In Ethereum, every program is processed by a network composed of thousands of computers.

Smart contracts are compiled into bytecode, which a component called EVM can read and execute. All nodes use their respective EVMs to execute this contract. By basic definition, every node in the network has a copy of the transaction and the network history of the smart contract. The EVM is responsible for executing the contract according to the rules pre-written by developers. The EVM computes this data based on stack-based bytecode, while developers write smart contracts in high-level languages like Solidity or Serpent.

Gas#

When each node in the Ethereum network executes a smart contract, it consumes a significant amount of energy (gas). Because consuming more energy means spending more money, it also depends on the level of programming of the smart contract. In other words, every low-level operation code in the EVM requires a certain amount of gas to execute its expected output.

Gas simply represents the cost of executing computations and helps developers understand the energy consumption of their smart contract code. Like the Bitcoin market, the value of gas is determined by the market. If a higher gas price is paid, nodes will prioritize these transactions for profit.

dApp#

dApps adopt incentive mechanisms such as cryptocurrency tokens and internal consensus mechanisms. Distributed applications do not need to store their entire state. However, distributed applications based on Ethereum do store their trusted state, providing an economical solution for end users.

In addition to the client interface with the Ethereum blockchain, dApp clients need to program the front end. Clients are typically written in JavaScript because they can run in web browsers, which most of us have.

dApp browsers use dApp clients (usually written in JavaScript) to interact with Ethereum nodes and then communicate with smart contracts. dApps ensure a connection with Ethereum nodes and provide a simple process for changing connections. It also provides users with an account interface so that users can easily interact with these dApps.

On this basis, we introduced some core components of Ethereum and observed how smart contracts operate in the real world.

Public Chain#

With a public chain, the process of linking blocks always uses various nodes, which can be independent, untrusted, or even unknown, and can participate in the consensus process to verify blocks. In a public chain, anyone can simply download the blockchain node client in the system and transact with anyone, and can read transactions through blockchain explorers. Bitcoin and Ethereum are some of the main examples of public chains.

Bitcoin is the first distributed platform to securely and reliably transfer funds. However, the purpose of Ethereum is different—to provide a platform for anyone to develop their own decentralized applications, not limited to just transferring currency but transferring any value. Ethereum uses smart contracts to implement a set of self-operating programs that execute when certain conditions are met.

Private Chain#

Organizations that set up private chains configure them as a permissioned network. Its establishment is to provide better transaction privacy and is suitable for banks and other financial institutions. Unlike public chains, simply connecting a blockchain node client to the internet is insufficient to initiate transactions; at the same time, a consortium chain only allows specific and pre-verified individuals to access and transmit any type of value through the network.

In this system, the consensus mechanism is controlled and managed by a pre-selected group of nodes. Thus, even if the blockchain operates on a public network, it is still restricted and can only be controlled and maintained by a specific group of nodes or even a single node. Private chains can also be referred to as consortium chains based on their level of restrictions and controls.

One of the most popular implementations is Hyperledger Fabric, a permissioned blockchain framework hosted by the Linux Foundation.

To understand the architecture and consensus model of blockchain, refer to https://www.researchgate.net/publication/318131748_An_Overview_of_Blockchain_Technology_Architecture_Consensus_and_Future_Trends.

Blockchain is the foundation of Bitcoin and has recently received widespread attention. Blockchain is like an immutable ledger that allows transactions to be conducted in a decentralized manner. Blockchain-based applications are emerging rapidly, covering a wide range of fields such as financial services, reputation systems, and the Internet of Things, but blockchain technology still faces many challenges such as scalability and security that need to be overcome. This article provides a comprehensive overview of blockchain technology. It first outlines the architecture of blockchain and compares several typical consensus algorithms. Additionally, it briefly lists the technical challenges and recent advancements. We also elaborate on potential future trends in blockchain development.

An experimental environment needs to be built specifically to demonstrate Hyperledger applications to address some practical issues in supply chain management. You need to obtain the source code at the link https://github.com/hyperledger/education.git.

Hyperledger is an open-source initiative aimed at meeting core industry needs through distributed ledger technology, created as a collaborative project by the Linux Foundation along with several industry giants in information technology, banking, logistics, transportation, finance, manufacturing, and the Internet of Things.

Today, cryptocurrencies are still committed to establishing trust with certain governments and corporate entities, and blockchain is the key technology used for secure business operations and management. Due to the inherent rigidity and static nature of Bitcoin, it is not suitable for commercial applications. While Ethereum has the capability to enhance the scalability of business applications through its smart contracts, financial institutions and other key business operations exhibit hesitation in attempting to use the Ethereum blockchain for their commercial operations due to its unrestricted use.

Hyperledger is the only distributed ledger technology framework specifically built for enterprises that need to adopt permissioned blockchains to achieve better control over the entire system. Because Hyperledger is more often used to solve critical business problems, it does not support any cryptocurrency platforms or related systems.

The Hyperledger project was established in December 2015 and has since received appreciation and adoption from many industry leaders, including Accenture, Airbus, American Express, Cisco, Fujitsu, Hitachi, IBM, Intel, SAP, NEC, BBVA, Bitmark, Bosch, CA Technologies, Capgemini, Ernst & Young, Factom, H3C, NSE, Oracle, PwC, Redhat, Samsung, Ripple, Thales, Wipro, and the Cloud Security Alliance.

The Hyperledger project also plans for collaboration between blockchain enthusiasts, the blockchain community, enterprises, and non-profit organizations, as well as the establishment of comprehensive unified standards for building distributed ledger applications. Just as WordPress revolutionized the way websites respond and launch, Hyperledger is working to reduce the cost and overall time of developing distributed ledger applications.

The Hyperledger project is widely praised for its pioneering work in developing cross-industry frameworks for platform collaboration. The financial industry has shown the most active interest in collaborating with the Hyperledger platform to keep up with development trends. Let’s review the project goals of Hyperledger to further understand its development roadmap:

· Community-driven infrastructure: As the Hyperledger project receives support from several private and government institutions, it provides an efficient, open, community-driven environment.

· Enterprise-grade framework: Unlike cryptocurrency blockchains, Hyperledger's development is designed to support enterprises in executing secure and reliable transactions or transaction processing through distributed ledger networks.

· Building a technology community: The project also aims to establish a larger and more effective technology community to innovate and develop blockchain smart contracts and other related code.

· Spreading blockchain awareness: This is a good way to spread awareness about blockchain technology and its business applications to enterprises and other institutions.

Hyperledger is an open-source framework that allows enterprises to build enterprise-grade solutions based on distributed ledger technology. The framework includes the following components:

· Shared ledger: A ledger that can only be appended to, storing data blocks in chronological order.

· Consensus algorithm: A protocol method for achieving consensus on changes to the content of the distributed ledger.

· Privacy: The primary purpose of building Hyperledger is to achieve a permissioned network with secure and reliable transactions in mission-critical business environments.

· Smart contracts: These are small program processes that users plan and process transaction requests.

Let’s understand the architecture of Hyperledger:

· Consensus layer: Primarily responsible for generating protocols for each order based on predefined rules and verifying transactions.

· Smart contract layer: Responsible for transaction requests and applying business logic.

· Communication layer: A platform used to assist communication between nodes through peer-to-peer transmission.

· Data storage abstraction: Allows other modules to use various data sources.

· Cryptographic abstraction: Allows the use of different cryptographic algorithms without affecting other modules.

· Identity service: Enables the use of additional identity authentication and authorization during blockchain setup.

· Rule service: Responsible for managing multiple rules, such as consensus rules, endorsement rules, and group management rules.

· API: Enables clients and applications to communicate with blockchain modules.

· Interoperability: Provides interoperability between different blockchain instances.

The structure of the Hyperledger framework is as follows:

· Iroha: Hyperledger Iroha is a blockchain framework contributed by Soramitsu, Hitachi, NTT DATA, and Colu. It is designed for mobile application developers under Android and iOS packages, featuring a simple design, including a C++ programming package and YAC consensus algorithm.

· Sawtooth: Provided by Intel, it allows the selection of various consensus algorithms based on network scale. By default, Hyperledger Sawtooth uses Proof of Elapsed Time (PoET) to achieve consistency between nodes. It is designed for versatility while supporting both permissioned and non-permissioned implementations.

· Indy: Hyperledger Indy is a distributed ledger for implementing decentralized identity business solutions and provides interoperability across multiple distributed ledger technology (DLT) supports. It aims to achieve privacy across nodes and throughout transactions.

· Burrow: Hyperledger Burrow is a permissioned smart contract system that provides a decentralized management smart contract interpreter built using the Ethereum Virtual Machine (EVM) for modular blockchain clients.

Establishing and maintaining communication between multiple nodes in the network is crucial:

· Node: There are three roles in the Hyperledger network:

· Client: The client submits transaction requests on the network. It must connect to a peer node to join the blockchain. The client has the right to connect the required peer nodes to the network.

· Peer node: Peer nodes listen for broadcast updates to the ledger and maintain copies. Depending on their nature, peer nodes can also be divided into two types:

· Endorsing peer: Responsible for checking and endorsing transaction proposals from clients.

· Committing peer: Confirms transactions before they are submitted to the network.

· Ordering service: The ordering service accepts endorsed transactions and stores them in order in a block, finally delivering them to committing peers. The ordering service also provides a shared and secure communication channel for client nodes and peer nodes. It acts as a medium for broadcasting transactions and helps users deliver them to peer nodes.

· Ledger: Like Bitcoin and Ethereum, the Hyperledger ledger provides a verification list of all valid and invalid transactions in the operation of the entire system. It is created by the ordering service and remains consistent with all peer nodes in the network.

· Channel: Channels in Hyperledger Fabric are restricted communication mediums for nodes to conduct confidential transactions. Channels are specific to members, shared ledgers, chaincode applications, and ordering service nodes.

Each peer node in a channel must be authorized by a member service provider (MSP), which verifies each peer node to its respective channel peer nodes and corresponding services.

· World state: This reflects the current data state of all assets in the network. Data is securely stored in the following formats:

· LevelDB: The default database for Hyperledger Fabric, which only stores key-value pairs.

· CouchDB: Best suited for web and local applications, it is essentially JSON. It meets all data storage needs by supporting binary.

· Chaincode: Chaincode is agreed upon and created by network members to execute business logic. It can be a program written in GO or Node.js:

· LevelDB: A default programming language that runs in a secure Docker container and manages ledger state.

· CouchDB: Another database programming language for storing JSON objects. It also supports key-value range queries, complex queries, and full data queries.

· Consensus: Consensus is the process of reaching an agreement on a set of transactions added to the ledger. In Hyperledger Fabric, consensus is achieved through the following three steps:

· Transaction endorsement.

· Ordering.

· Validation and confirmation.

Now, let’s understand these consensus components and how they operate with Hyperledger and its transaction processing methods.

The work and transaction processing flow of Hyperledger can be explained as follows:

1. Transaction submission: In Hyperledger Fabric, the entire process begins with the client application submitting a transaction:

Each client application can submit transactions to endorsing peer nodes for simulation processing and endorsement.

2. Endorsers send the RW set to the client: Each endorsing peer node simulates the proposed transaction and stores a read-write data set called the RW set. These data sets are signed by the endorsing peer nodes and returned to the client application:

Transaction endorsement: This is the signed response generated by the simulated transaction. Like smart contracts, there can be multiple ways to define transaction endorsement through policy chaincode. A transaction endorsement policy is similar to a defined chaincode.

3. Client application service: Once the client application receives the RW set and the approved transaction, it must submit these transactions to the ordering service. This method continues regardless of whether other client applications have confirmed the transaction endorsement and RW set:

4. The orderer sends transactions in blocks to committing peers: The ordering service accepts the RW set and endorsed transactions, organizes them into blocks, and forwards them to committing peers:

The ordering service is responsible for organizing all transactions and then submitting them to the ledger. By default, the ordering service of Hyperledger Fabric is Kafka, an open-source stream processing platform developed by the Apache Software Foundation (ASF).

Now, let’s take a closer look at how the ordering service works. It is essential to break it down into several core parts:

· Part 1 of the ordering service: Once a certain number of transactions are prepared within a specified time frame, a block is created, and these transactions are submitted in chronological order. Unlike the Bitcoin blockchain, Hyperledger Fabric provides the most suitable ordering mechanism, which helps enterprises design fine-grained, flexible, and scalable distributed network systems.

· Part 2 of the ordering service: Hyperledger Fabric supports three ordering service mechanisms—SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT):

· SOLO: Most suitable for software developers for research and testing, with only one ordering node.

· Kafka: Another ordering mechanism for production use in Hyperledger Fabric. It is developed by ASF and provides a unified, efficient, low-latency software platform for processing real-time sources. In Hyperledger Fabric, Kafka processes RW sets and endorsed transactions.

· SBFT: Similar to the PoW consensus mechanism of the Bitcoin blockchain. This solution is designed to overcome Byzantine faults. The system can still function normally even if there are malicious nodes or a group of malicious nodes in the network.

5. Committing peers validate each transaction in the block: Committing peers validate transactions to ensure that the RW set matches the current world state. Once committing peers validate the transactions, they are updated in the ledger, and the world state is updated by default using the write data from the RW set:

Finally, committing peers must notify the client application of the success or failure of the transaction.

6. Authentication: At every step of the transaction process, from endorsement to version checking, authentication remains an ongoing process.

Bitcoin, Ethereum, and Hyperledger#

The characteristics of blockchain platforms enable a deeper understanding of the comparisons between popular blockchain platforms:

· Permission restrictions: Defines the qualifications for transaction processors to create or block existing ledgers. In this context, there are two types:

· Permissioned blockchain: In this model, transaction processing can only be performed by pre-selected users. Hyperledger Fabric falls into this category.

· Permissionless blockchain: This model does not restrict transaction processors from creating or adding new blocks. Ethereum and Bitcoin are currently the most popular permissionless blockchains.

· Restricted data access: Specifies the reading permissions of the blockchain network. There are two types:

· Public blockchain: There are no restrictions when reading ongoing transaction information. Anyone can use the blockchain node client to download the updated blockchain ledger.

· Private blockchain: In this type of blockchain, access to the blockchain ledger is limited to pre-selected users.

· Consensus mechanism: Achieving a trustless network in a distributed network and determining consensus on all transactions is crucial. This ensures that only valid and legitimate transactions are added to the blockchain. Common consensus algorithms include PoW, PoS, and PBFT.

· Scalability: Scalability depends on two factors—nodes and performance. Node scalability refers to the ability to add nodes to the blockchain network without affecting overall performance, and scalability depends on the number of transactions per second.

· Anonymity: Refers to the public or hidden identities of users in the blockchain.

· Governance: The decision-making power allocated within the blockchain community. Blockchain platforms must be maintained by a core development team or other stakeholders.

· Native currency: Refers to the valid currency within the blockchain, such as Bitcoin in the Bitcoin blockchain.

Scripts: Refers to the programming level supported by distributed applications (dApps):

Details about blockchain and the CIA triad model:

· Visit https://ethereum.stackexchange.com/questions/25270/confidentiality-in-blockchain to learn about confidentiality in blockchain.

· Visit https://gdr-securite.irisa.fr/redocs/download/redocs17-gemalto.pdf to learn about data confidentiality in private chains.

PKI Analysis#

The internet allows anyone to connect with others, and unlike the real world, there are no geographical or physical barriers. This makes it very difficult to correctly identify a person on the internet and establish further trusted communication. In the diagram below, Alice wants to have a session with Bob over the internet; however, Bob refuses because he cannot verify Alice's identity.

PKI solves this problem by adding a trusted third party (TTP) between Bob and Alice. Before they start to understand each other, they must establish a trust relationship, and TTP helps facilitate this process. In the diagram below, Alice shares a digital certificate with Bob, who uses the public key from the certificate authority to verify Alice's signature, thereby authenticating Alice.

In the above diagram, TTP is the Certificate Authority (CA). The CA helps users establish their identity on the internet by generating a certificate:

· PKI: PKI provides a hierarchical standard to manage the digital assets of entities, thereby establishing a secure communication channel. Moreover, PKI is not limited to user use; it is also widely used in various different application systems, such as email, web applications, smart cards, etc., which will be further introduced later.

· Network devices: PKI is used to control access to routers and switches, performing authentication based on 802.1X.

· Applications: Applications need to obtain signed certificates from the CA to run in the operating system.

· IPsec tunnels: Routers and firewalls use certificates to authenticate other endpoints on the network.

· Radius servers: PKI certificates protect Lightweight Directory Access Protocol (LDAP) queries.

An implementation of PKI architecture, initially detailed in X.509 design, elaborates on the process of certificate storage and public key distribution through CA digital signatures. However, the X.509 profile does not detail how to support many subfields and extensions of certificates, as shown in the diagram below:

Through the joint efforts of various standard-setting bodies, an outline was eventually prepared for X.509 version 3 PKI and version 2 certificate revocation lists, among other content. Before the formal release of RFC 2459, about 11 drafts were proposed to enhance the X.509 standard.

RFC 2510 was developed to specify the message protocols used in PKI. Subsequently, two parallel development lines emerged in response to the need for an increased registration protocol and preference for the PKCS#10 message format. The diagram below explains the evolution of the PKI information header. In version 2, the unique identifier ID of the publisher and the unique identifier ID of the subject were added to the information header. In version 3, an extension field was introduced to identify rules and other related information, as shown in the diagram below:

Additionally, the syntax for certificate requests was developed in the S/MIME WG with PKCS#10. RFC 2510 defines a simple user registration protocol, but it does not use PKCS#10 as the certificate request format.

Components#

PKI is a collection of various components, applications, rules, and practices that collectively ensure the implementation of integrity, authentication, and non-repudiation, the three elements of security. Digital certificates are the main components of PKI, serving as digital IDs on the internet. The following introduces the five core components of PKI.

1. Asymmetric key encryption

In cryptography, encryption is the process of encoding information to ensure that only relevant parties can view and understand the original information. This encoding process for encrypting information can be achieved in two ways: symmetric encryption and asymmetric encryption, explained as follows:

· Symmetric encryption: In symmetric encryption, the data encryption and decryption process uses the same key. This requires both parties to use the same key for data encryption and decryption, as shown in the diagram below:

· Asymmetric encryption: In asymmetric encryption, different keys are used to encrypt and decrypt data. Each key pair consists of a public key and a private key. The public key is used to encrypt data, while the private key is used to decrypt data. The public key exists alongside data on the internet, while the private key is the responsibility of the individual user who uses it, as shown in the diagram below:

Public and private key pairs can consist of two uniquely related graphical keys. Below is an example of a public key:

The public key is provided to everyone over the network and stored in accessible storage or directories. On the other hand, the private key must be kept private by its owner, so it is sometimes referred to as the key. The public key and private key are mathematically related. Data encrypted with the public key can only be decrypted by the corresponding private key.

2. Certificates

A certificate is an electronic ID that represents the identity of a user or device wishing to communicate over the network. The certificate essentially ensures that only legitimate users can connect to the network. Certificates are generated by trusted third parties (i.e., CAs) signing the public key.

The following are three common types of certificates:

· Secure Socket Layer (SSL) certificates: SSL server certificates are installed on the server host, such as web applications, mail servers, directories, or LDAP servers. This certificate contains identifying information about the organization to which the application belongs. SSL certificates also contain a system public key. The subject of the certificate matches the hostname of the server. This certificate must be signed by a trusted certificate authority. The primary hostname is listed as the common name (Common Name) in the certificate subject field.

· Client certificates: Client certificates are used to identify network users, devices, gateways, or any other type of device. It is a digital credential used to verify the identity of the client holding the certificate. Today, many applications allow user authentication for specific resources through certificates instead of usernames and passwords. Two users communicating via email can also use client certificates to authenticate each other's identities.

· Code signing certificates: Code signing certificates are used to sign software running on systems. In a scenario where millions of applications are downloaded on user machines, verifying program code is essential, so code signing certificates play an important role.

· Email certificates: The sender needs to select the corresponding public key for any given recipient using the S/MIME protocol. The sender can obtain this information from the email certificate. Typically, when emails are communicated within an organization and use their own CA, the S/MIME protocol is used.

3. Certificate Authority

A Certificate Authority (CA) is a trusted third-party organization that proves that users, servers, databases, and administrators are as they claim to be. The CA checks the credentials of users and issues certificates, signing them with keys. A CA can be an open solution or a regulated solution that provides certificate services, as shown in the diagram below:

The functions of a CA are as follows:

· Issue and deliver certificates.

· Publish certificates and certificate revocation lists (CRLs) to repositories.

· Manage revocation requests from certificate owners.

In the screenshot below, we can see a list of digital signatures in the client system. The certificates in the list are issued by multiple certificate authorities and have their respective validity periods:

Different types of CAs are as follows:

· Public digital certificate authorities: Some public certificate providers manage certificates for commercial and personal purposes. These digital certificates issued by CAs can only be obtained after paying a specific fee.

· Private digital certificate authorities: System administrators of enterprises or organizations can issue certificates to system applications and users within the domain. For example, Windows servers can create and store key pairs, but these private certificates are invalid for external communication and are limited to internal use.

4. Registration Authority

A Registration Authority (RA) is responsible for authenticating the identity of new entities that need to be trusted. It also maintains local registration data and initiates the renewal and revocation process of old certificates.

The functions of an RA are as follows:

· Responsible for authenticating the identity of new users or systems that require CA certificates.

· Responsible for performing some functions of the CA.

· Acts as an agent for the CA.

· Responsible for updating and maintaining local registration data for certificate renewals and revocation processes.

5. Certificate Repository

A Certificate Repository (CR) is a certificate database that can be accessed by all nodes in the PKI environment. It also stores revocation information and policy information related to certificates. This repository obtains updated certificate lists in the form of certificate revocation lists.

The functions of the certificate repository are as follows:

· It allows information to be retrieved in an unauthenticated manner.

· It serves as a database to store public key certificates, revocation lists, and policies, among other information.

The PKI architecture operates on a model called the trust chain. This model exists in the trust relationships between each identity. Specifically, the distinction between two-layer and three-layer hierarchies is that the second layer places the root CA (root CA) or issuing CA (issuing CA). The primary reason for using a two-layer CA is to set up a policy CA (policy CA) responsible for issuing certificates to the certificate-issuing CA. Thus, the three-layer hierarchy can provide better security. The policy CA can also serve as the management boundary of the system. If an administrator needs to revoke many CAs due to key leakage, this design is useful as revocation can be executed at the second layer while keeping other branches of the root available, as shown in the diagram below:

During the signing process, the root CA digitally signs the intermediate certificate using its key pair. This process guarantees the authenticity of the issued certificates, declaring that the issued intermediate certificates are trusted by the root CA. Each CA can receive authorization requests from clients and issue certificates. Typically, clients cannot access the root CA, but clients are eligible to hold root CA certificates. Clients send certificate requests to their respective CAs to obtain installed certificates, as shown in the diagram below:

In the diagram below, we can see the flow of shared digital certificates and their decryption. To authenticate the identity of one party, digital certificates use public keys for decryption:

Understanding the hierarchy of digital certificates with identities, intermediaries, and root certificate authorities, let’s see how to establish a trusted connection communication between the browser client and the SSL-enabled website. The client requests access to an HTTPS website. The client's browser pre-loads many root CA certificates. The steps are as follows:

1. The client connects to the SSL-enabled website.

2. The website returns its identity and intermediate certificates to the client.

3. The client uses the public key of the intermediate certificate to decrypt the digital signature, thereby confirming the authenticity of the intermediate certificate.

4. The client verifies that the requested URL matches the URL in the identity certificate. If it does not match, a warning will be displayed.

5. The client uses the public key to encrypt or decrypt traffic, while the server uses the private key to encrypt or decrypt traffic.

Multi-key encryption cycle flowchart:

We can further understand several stages of using and processing keys:

· Key creation: Keys are generated and stored on the key management server. The key manager uses a secure random bit generator to generate key pairs through the encryption process. Once the key pair is created, it is stored in the key storage database along with all its attributes. Attributes typically consist of name, size, instance, activation date, flip, mirror value, key access, and other associated attributes. Key activation time can be scheduled, or the key can be activated at the time of creation. The encryption key manager tracks the current and past instances of encryption keys.

· Key usage and rolling updates: The key manager is responsible for allowing authorized users or systems to retrieve information and enabling them to process encryption or decryption. It is also responsible for managing the entire lifecycle of encryption keys and the status of each key instance. If an organization’s policy states that it should use a new set of keys every year, the key manager should retain previous versions of the keys while only distributing the current version. However, to perform the decryption process, previous versions can still be retrieved.

· Key revocation: Administrators connect to the key management server to revoke keys so that they are no longer used for further encryption and decryption processes. If necessary, administrators can even reactivate keys and use them for subsequent processes. In some cases, administrators can also use data decrypted from previously encrypted data (such as from old backups). The key lifecycle is shown in the diagram below:

· Backup (third-party hosting): NIST recommends archiving all deactivated keys. This archive must be protected from any unauthorized modifications or deletions. It is also recommended to provide a recoverable key mechanism after the end of its key lifecycle.

· Key deletion (destruction): If a key is leaked or has not been used for a long time, administrators should choose to delete the key from the key storage database of the encryption key manager. The key manager deletes the key and all its associated instances, or it can specifically delete certain instances. This option plays an important role when compromised data is in an encrypted state. If the key is deleted, the compromised data will be completely secure and unrecoverable, as the same encryption key cannot be recreated.

The Key Management Interoperability Protocol (KMIP) is used for communication between clients and servers, performing management operations on storage objects maintained by key management systems. This is a standardized approach to managing encryption keys throughout their lifecycle, developed to facilitate the symmetric and asymmetric encryption keys, digital certificates, and other related templates to simplify object creation and management, as detailed below:

The Organization for the Advancement of Structured Information Standards (OASIS) is a non-profit organization that provides standards for people to exchange information over the web and within organizations. According to OASIS guidelines, clients can request a series of objects and operations from the key management server:

· Create keys or key pairs: Request to generate new symmetric keys or new public/private key pairs and register new managed encryption objects.

· Registration: Register managed objects with keys, passwords, or other encryption materials.

· Replace keys: To generate replacement keys (also known as changing keys), replacement keys are used for existing symmetric keys or existing public/private key pairs.

· Derive keys: To obtain symmetric keys, derived keys are used to obtain data objects already known to the key management system.

· Locate: To find one or more managed objects, the locate request is used to obtain the properties specified in the request.

· Check: Check the usage status of managed objects based on values specified in the request.

· Obtain properties: Used to return the managed object specified by its unique identifier or multiple properties associated with the managed object.

· Add, modify, or delete properties: These properties are used to add, delete, or modify instances of properties associated with managed objects.

· Activate: Used to activate managed encryption objects.

· Revoke: Used to revoke managed encryption objects.

· Destroy: Used when it is necessary to destroy the critical materials of specific managed objects.

· Archive: Used to specify the archiving of managed objects.

· Restore: Used to access the data recovery process.

Challenges Facing the PKI Model#

Issue 1—Additional security requirements: According to a report by the Ponemon Institute in 2016, 62% of enterprises have deployed PKI for cloud-based applications, an increase of 50% from 2015. If the central certificate repository is compromised, it can lead to massive data breaches and account theft. Organizations tend to use additional security layers, such as Hardware Security Modules (HSM), to protect their PKI. HSMs are used to protect the most critical roots of PKI and are used to issue CA private keys. Organizations tend to choose multi-factor authentication for administrators and HSMs.

· Issue 2—Centralized authorities: In the current state of the network, centralized authorities (root authorities) are responsible for managing DNS requests and responses (root authorities), X.509 certificates, etc. Therefore, all connected devices and systems must trust third parties to manage public keys and identifiers. For example, a domain, although purchased by its owner, is actually controlled and regulated by third parties (such as the Internet Corporation for Assigned Names and Numbers (ICANN), domain registrars, or certificate authorities).

Moreover, these trusted third parties have the ability to compromise and damage the integrity and security of user data worldwide. In some cases, these trusted third parties have shared customer information with security enforcement agencies and other organizations. They can do this for economic gain or for user behavior analysis.

Due to its centralized management mechanism, PKI has significant vulnerabilities. Blockchain, fundamentally decentralized and trustless, allows communication between multiple participants without the need for any third-party involvement. A decentralized approach could be a paradigm shift for PKI; however, a systematic approach is needed for deployment and implementation.

Blockchain is a multi-party distributed network without the involvement of third parties. Distributed Public Key Infrastructure (DPKI) is a new concept that implements an identity authentication system on a public system without relying on a single third party that may compromise the integrity and security of the system. As we already know, blockchain is built using a method based on distrust, allowing trusted and untrusted multiple parties to communicate with each other. However, trust is often established between geographically and politically different participants who have several consensus models regarding the state of the ledger. By definition, blockchain allows multiple nodes in the network to store any type of value. For DPKI, this value will be confidential.

Subjects can directly control globally readable identifiers, such as website domain names, by registering identifiers on the blockchain. For the key database, subjects use identifiers to look up keys. Blockchain can allow the allocation of confidential assets, such as public keys and other attributes, and allow these values to be globally readable in a secure manner, without being compromised by any MITM, which can be achieved in PKIX. This is achieved by allowing the correct public key to link to the identifier value, while authentication is performed by looking up the latest public key through the identifier.

In the design of DPKI, although the system is decentralized, identifiers are still controlled by the subjects, eliminating the risk of identifier data storage being compromised.

Decentralized PKI (DPKI)

Decentralized Public Key Infrastructure (DPKI) is another approach to designing a better PKI system. Pretty Good Privacy (PGP) is an encryption program developed by Phil Zimmermann, a decentralized trust system created before the existence of blockchain.

It relates to establishing trust relationships between parties. But today, there is no need for a third party. Blockchain is a new way to establish a more capable and secure PKI system.

But how does blockchain improve PKI? In decentralized PKI, blockchain acts as a decentralized key-value store. It can protect data reads against MITM attacks and minimize the capabilities of third parties. By introducing the powerful capabilities of blockchain technology into the system, DPKI addresses the issues of traditional PKI systems.

The decentralization of the management framework can resolve the issues of CA systems regarding certificate revocation, eliminate single points of failure, and quickly respond to CA abuses. Blockchain can make processes transparent, immutable, and prevent attackers from intruding, effectively avoiding MITM attacks.

In 2015, Allen et al. explored in a publication titled "Decentralized Public Key Infrastructure" that, unlike traditional methods, DPKI ensures that no single third party can compromise the integrity and security of the entire system. In blockchain-driven DPKI, new third parties become miners or validators.

Trust is established and maintained based on consensus protocols. Third parties, miners or validators, must adhere to the rules of the protocol, which will economically reward and punish these third parties to effectively prevent misconduct in the blockchain and limit their roles.

The authors wrote in their 2015 paper, "By using technology that enables geographically and politically different entities to reach consensus on the state of a shared database, blockchain allows for the allocation of arbitrary data, such as the public keys of these identifiers, allowing these values to be globally readable in a secure manner, making them less susceptible to MITM attacks that may occur in PKIX."

Additionally, researchers believe that the logic of key management can be implemented on smart contracts in the blockchain, and "using smart contracts in the blockchain to implement privacy-based decentralized public key infrastructure (PKI)" was successfully implemented in the 2017 publication by Sivakumar P and Kunwar Singh.

However, blockchain is still not perfect, as it requires a device to synchronize consistent consensus data. Today's Geth (Go-Ethereum) clients provide multiple types of synchronization modes: full sync, fast sync, light sync. The blockchain project Diode, based in Taiwan and the United States, recently developed a lightweight client protocol called BlockQuick, designed to establish decentralized trust with low bandwidth.

The following table compares different types of synchronization modes, trust models, bandwidth, and duration for Geth, FlyClient, BlockQuick, and traditional web PKI clients.

Ethereum is one of the most flexible and reliable platforms among many blockchain platforms. It is a programmable blockchain suitable for granular and policy-based PKI systems. PKI can be implemented through smart contracts in the Ethereum blockchain. Each entity can have multiple attributes to authenticate ownership, and these entities can be public keys or Ethereum addresses. Each transaction uses a public key identifier, which is then represented by the corresponding entity ID and PKI. Smart contracts are used to program events and functions for various operations in PKI. Smart contracts can also be configured to call specific PKI operations, such as creation, derivation, deletion, destruction, etc. These functions and processes will be written and deployed reliably in the EVM, providing convenient user management for PKI operations. The following PKI operations are provided through smart contracts:

· Entity registration: Users or systems are added to the PKI system by calling the registration event from the smart contract. Entities can be simple, such as Ethereum addresses, public keys, attribute IDs, data, and data hashes. Events configured on the smart contract will collect entities and forward them as transactions to Ethereum. Through the mining consensus process, transactions in the queue are packaged into blocks and attached to the blockchain.

· Attribute signing: Entities can be characterized through registration events. Each attribute of an entity can be signed by the PKI system via smart contracts, issuing transactions. This signed entity will later be provided to other entities or users.

· Attribute retrieval: Attributes of entities can be located through filters applied to blockchain applications, using the respective IDs of events configured on smart contracts as indexes.

· Revocation of signatures: This is one of the most critical functions required for any PKI solution to revoke digital signatures on attributes or entities. Revocation of signatures becomes extremely important when a user loses their key or if the key is compromised. Smart contracts can be configured to call revocation events and revoke signatures on specific entities.

In DPKI deployment, the registration authority still plays a role in the infrastructure, but its role is limited to ensuring that the identity of entities is represented in the network:

· It is necessary to ensure that the software is always under the control of the subject and the corresponding key.

· Private keys must be generated in a distributed manner to ensure that they remain under the control of their respective subjects. It must be strictly prohibited to generate key pairs for other subjects.

· No entity can modify other entities without the consent of the subject.

· Once a namespace is created in the blockchain through Ethereum smart contracts, it cannot be destroyed. The registration and updating of identifiers must be transparent.

· By default, the software managing identifiers must ensure that all operations (such as creating, changing, updating, or deleting identifiers) are forwarded through a decentralized mechanism.

Experiment#

First, open Node.js and the Ganache-CLI framework. When creating the entire Ethereum environment on the local system, the installation of ganache-cli must be executed carefully. Follow these steps:

1. Install Node.js using the commands displayed at https://nodejs.1.org/uk/download/package-manager/#arch-linux.

2. Run the following command in the terminal:

Now, we use the command shown in the image below to start the test network:

3. Now we must enable developer mode to view browser content in detail. The LOAD UNPACKED extension option must also be opened, as shown in the screenshot below:

The CA can publish a response policy (RP), which will come into effect if unauthorized certificates are issued. During testing, we need to register a Domain Certificate Policy (DCP) and create a response policy. Testing can be completed on the local system through the following steps:

1. First, we need to add a detector and register it. The following script is needed to add the detector by defining the detector ID:

2. We will now register a domain owner for issuing certificates from the CA. We need to define the CA ID, the address of the CA owner, and the name, as shown in the image below:

3. Register the DCP with the CA, as shown in the image below:

4. Create a related RP under the smart contract, as shown in the image below:

5. When the detector receives a report of a malicious certificate, revoke the certificate, as shown in the image below:

6. When the CA frequently exhibits erroneous behavior, the detector can blacklist the CA, as shown in the image below:

In the above process, we successfully deployed PKI on the Ethereum blockchain. With this infrastructure, we described the entire process from registering the CA to requesting response payments. We successfully developed a model describing response payments and developed a method to hold errant CAs accountable.

PKI framework and related technologies:

· Learn about the fundamentals of PKI technology at http://www.oasis-pki.org/resources/techstandards/.

· Learn about IKP: Changing PKI with blockchain technology at https://eprint.iacr.org/2016/1018.pdf.

· Learn about PKI at https://www.ssh.com/pki/.

Blockchain's DNS Security Platform#

The primary role of the Domain Name System (DNS) is to resolve queried hostnames into IP addresses. Internet users typically access certain web pages via domain names, such as www.packtpub.com, but the internet requires an IP address to route access requests to the desired destination. Therefore, DNS acts like a telephone book for the internet, allowing everyone to use it globally, which certainly also makes it susceptible to abuse. In this chapter, we will learn about DNS infrastructure, core components, the challenges faced by existing systems, and how blockchain could transform and optimize these functions. In this chapter, we will cover the following topics:

· DNS.

· DNS structure and hierarchy.

· DNS topology for large enterprises.

· Current challenges facing DNS.

· Blockchain-based DNS solutions.

· Experiment.

DNS is a core service of the internet. If DNS is unavailable, it would be challenging for all of us to find resources on the internet. As a massive telephone book for the internet, the entire online system heavily relies on DNS. It is due to the existence of the DNS naming space that we do not need to remember lists of IP addresses but only need to remember the names of web pages (domain names).

For IT and security professionals, understanding the basic structure, function, and operation of DNS is very important. DNS is a hierarchical database system with authoritative agents. For the scope described in this chapter, we will consider enterprise-level DNS deployments and their functions. Enterprises or organizations can manage their DNS infrastructure in two ways—by allowing Internet Service Providers (ISPs) to manage it or by managing it internally. Any misconfiguration or failure in the ISP network will affect the enterprise's internet infrastructure.

As the number of internet users continues to grow, DNS has become a business pillar for internet enterprises, and this importance makes it necessary for enterprises to tightly control their DNS. Through efficient DNS deployment, enterprises can even achieve more effective spam filtering and network topology optimization. Here are several ways DNS plays an important role in enterprises:

· Anti-spam: Certain DNS mechanisms (including Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)) ensure that only domains on a predefined list can send emails on behalf of the corresponding organization. This mechanism is only effective when DNS within the organization is functioning correctly.

· Load sharing: DNS services can optimize server infrastructure by distributing traffic, allowing low-load servers to share the traffic of high-load servers.

· Privacy: DNS services protect the privacy of organizational naming space information by masking addresses with different domain names, primarily depending on whether they are accessed from within or outside the network, thus contributing to stronger network security.

TLDs are one of the highest levels of domains in the DNS hierarchy. TLDs are set in the root zone of the naming space. The domains in the final part of the system must be identified using fully qualified domain names. The Internet Corporation for Assigned Names and Numbers (ICANN) ensures that TLDs are managed by authorized organizations. The Internet Assigned Numbers Authority (IANA) operates under ICANN and is responsible for managing the DNS root zone.

IANA is responsible for managing the following TLDs:

· ccTLD—Country Code TLD.

· gTLD—Generic TLD.

· .arpa—Infrastructure TLD.

The hierarchical diagram below illustrates the existing TLD structure:

DNS stores a vast database of domain names. To execute the registration process, three entities must work together—registration authorities, registrars, and registrants.

· Registration authorities: These organizations maintain the naming space database and have editing rights over it. Registration authorities operate authoritative NS for the naming space and manage TLD names. Their responsibilities include creating domain name extensions, setting rules for domain names, and collaborating with registrars to provide domain names to the public. For example, Verisign manages the .com domain and its DNS registrations.

· Registrars: These organizations hold domain names and are authorized to sell domain names to the public. These registrars must be accredited by generic top-level domain (gTLD) registries or country code top-level domain (ccTLD) registries. Registrars operate under the guidelines of domain name registration authorities.

Only designated registrars can modify or delete information related to domain names in the central registration database. End users purchase domain names directly from registrars, and end users have the right to change registrars, meaning they can migrate domain names between registrars. Some of the most popular registrars include GoDaddy, HostGator, BigRock, etc.

· Registrants: End users who hold domain name rights. As domain registrants, everyone has certain rights and responsibilities, including obtaining information from their registrars about the processes for registering, managing, migrating, renewing, and recovering domain registrations.

DNS records are mapping files associated with DNS servers. Regardless of which IP address a domain name is associated with, these servers handle DNS requests sent to each domain. Various strings function similarly to behavioral components running in DNS servers, and these command strings are called DNS record syntax. These records include A, AAAA, Canonical Name (CNAME), Mail Exchange (MX), Pointer (PTR), Name Server (NS), Start of Authority (SOA), Service (SRV) records, Text (TXT), and Naming Authority Pointer (NAPTR). Let’s explore these DNS records in detail.

· SOA: SOA records describe the beginning of the zone file. It consists of the zone name, technical contact point, NS, serial number, and timeout value:

· NS: NS records identify the authoritative domain name servers for the zone. NS also delegates subdomains to other organizations on the zone file. In the previous example, we can clearly see the list of NSes for www.google.com.

· Record: The establishment of address records is from name to address forward binding. In this example, we use the domain www.google.com to map to the IP address:

· MX records: These are used to identify servers that can exchange emails. Priority is always associated with each record, allowing users to configure primary and backup mail servers.

· TXT records: These records provide an extended method of providing information through DNS. This text record stores information about SPF, which can identify authorized servers to send emails on behalf of your organization.

· CNAME: CNAME essentially serves as an alias for binding traffic to domain and subdomain text. They indicate that the Secure File Transfer Protocol (SFTP) server is on the same system as the mail server. CNAME plays an important role, especially when the server is not directly controlled, such as hosted web servers.

· PTR records: These records are used to provide reverse binding from address to name. PTR records should match the forward mapping exactly.

Ethereum's Secure DNS Infrastructure Experiment#

Blockchain technology has the potential to transform multiple industries, so in this chapter, we will use it to manage domain name servers to address some of the most critical DNS challenges. One of the most active projects to protect the DNS framework from deception is DNSChain.

DNSChain is a blockchain-based DNS software suite that replaces the X.509 public key infrastructure (PKI) and provides MITM authentication proof. It allows internet users to set up public DNSChain servers for DNS queries and access servers with domain names ending in .bit.

X.509 is a standard framework that defines the format of PKI for identifying users and entities on the internet. It helps internet users verify whether the connection to a specified website is secure. DNSChain can provide a scalable distributed alternative that does not rely on third parties.

Public key locking technology can be used to eliminate the MITM attack problem. Public key locking can specify two pin-sha256 values, i.e., specify two public keys. One is the lock for any public key in the current certificate chain, and the other is the lock for any public key not in the current certificate chain:

· This scheme works in parallel with existing DNS servers.

· Websites and users can store their public keys on the blockchain.

· Keys are shared through the DNSChain software framework.

The DNS infrastructure has always been one of the most at-risk assets on the network. Traditional DNS is vulnerable to various complex threats. Moreover, since the current DNS system is hierarchical, the root servers of the system become high-value attack targets. Because the entire infrastructure is centralized, even a slight failure can lead to the failure of the entire system. A group of engineers—Greg Siepak and Andrea Devers—developed a blockchain-based DNS service platform to connect clients and domain name servers without the involvement of any third parties. This project is called DNSChain and is hosted on GitHub at https://github.com/okTurtles/dnschain.

Configure the DNSChain server in Ubuntu. The experiment will run PowerDNS Recursor, expected to publish DNS queries for .com and .net domains but will query the local Namecoin blockchain to resolve .bit