Recap

In our first series, we covered the following 7 articles:

• Review of top 7 modern cyber attacks for IT security professionals
• How Distributed Denial-Of-Service (DDoS) Attacks Work
• How Advanced Persistence Threat works
• What Is the Zero-Trust Approach in Cybersecurity
• The assume breach approach in cybersecurity
• The impact of the CIA security triad on blockchain technology
• Two-Factor Authentication with Blockchain

 

Note

If you are new to the field of cybersecurity, taking our Inro to Cybersecurity (free self-paced) course is highly recommended. Also, if you are already familiar with cybersecurity, taking our Intro to Blockchain Cybersecurity course is highly recommended.

 

Organizations have many applications to manage, and these are hosted by different systems and servers. Organizations have deployed several ways to authenticate users, based on methods such as multi-factor authentication, one for each system/application, Single Sign-On (SSO), and the directory server; however, authenticating users on the internet is a comparatively difficult mechanism. It is also extremely important to achieve trust over the internet before exchanging information because the internet has been kept open for trusted and untrusted parties. In order to established trust over a public network, there is the need for an independent trusted party. A Public Key Infrastructure (PKI) is an open framework built to resolve trust factors between internet-connected users.

In this article, we will learn about the following topics:

• Public key infrastructure
• Challenges of the existing PKI model
• How can blockchain technology help?

 

 

PKI

Organizations may have hundreds of cloud-based applications to manage and maintain. Managing individual access control and authentication is a difficult daily task. When it comes to internet users and enormous web applications, it becomes difficult to trust individual websites, and users tend to lose their private and confidential information through them. A PKI provides a secure means of authenticating an individual's identity.

Businesses can reduce the number of deployment and management issues that are encountered with applications by employing a PKI. As businesses are moving more toward cloud-based applications, it is critical to protect security-sensitive applications from emerging threats. There are many security threats when communicating online such as identity theft, Man-In-The-Middle (MITM) attacks, and data leaks.

 

PKI in a nutshell

The internet allows anyone to connect to anyone else and, unlike the real world, geographical/physical barriers don't exist. This makes it difficult to identify a person over the internet and establish trust for further communication. In the following diagram, Alice wants to talk to Bob over the internet; however, Bob refuses because he doesn't have any means of verifying Alice's identity:

 

 

The PKI solves this problem by appending a Trusted Third Party (TTP) between Bob and Alice. So, before they can start getting to know each other, they have to establish trust and the TTP helps to accomplish that. In the following diagram, Alice shares a digital certificate with Bob and Bob uses the public key from a trusted certificate authority to decrypt this signature and authenticate Alice:

 

 

                                                                   
In the preceding diagram, the TTP is the Certificate Authority (CA). This CA generates a certificate that helps an internet user show his/her identity over the internet:

• PKI: A PKI provides a hierarchical standard to manage the digital assets of an entity to establish a secure communication channel. It is not just limited to users; it is also used by several different systems such as emails, web applications, smart cards, and more, which will be explained later.
• Network devices: A PKI is used to control access to routers and switches with 802.1X authentication.
• Applications: Applications need to get a signed certificate from a CA to run in the OS.
• IPsec tunnels: Routers and firewalls use certificates to authenticate other endpoints over the internet.
• Radius servers: A Lightweight Directory Access Protocol (LDAP) query is protected with PKI certificates.

 

The following diagram shows PKI security architecture:

 

The evolution of PKI

The X.509 design elaborates data formats and procedures for the storage and distribution of public keys through certificates that are digitally signed by CA. However, X.509 does not include a profile to specify supporting many of the certificate's subfields and extensions, shown as follows:

 

The standard efforts prepared an outline for PKI of X.509 version 3 as well as version 2 certificate revocation lists. Before moving on to RFC 2459, there were around 11 drafts to enhance the X.509 standard.

RFC 2510 was developed to specify a message protocol used in PKI. After this, there were two parallel developments with the need of an enrollment protocol and the preference to use the PKCS#10 message format. The following diagram explains the evolution of the PKI header. In version 2, a unique issuer ID and unique subject ID were added to the header. In version 3, an extension field was introduced to identify policy and other related information, illustrated as follows:

 

Furthermore, the certificate request syntax was developed in S/MIME WG with PKCS#10. With RFC 2510, a simple enrollment protocol was defined, but it did not use PKCS#10 as a certificate request format.

 

Components

PKI is a collection of a wide variety of components, applications, policies, and practices that combine and accomplish the three security principles, which are integrity, authentication, and non-repudiation. Digital certificates are the main components in PKI as they act as a digital identity over the internet. The five core components of PKI are explained in the following subsections.

Asymmetric key encryption

In cryptography, encryption is the process of encoding information so that only the intended party can see it. There are two methods of accomplishing this cryptography encryption, symmetric encryption and asymmetric encryption (take our free Intro to Cybersecurity course to learn more about encryption methods), defined as follows:

• Symmetric encryption: In symmetric encryption, the same key is used for the encryption and decryption of data. It is needed to ensure that both parties use the same key to encrypt and decrypt the data, shown as follows:

 

• Asymmetric encryption: In asymmetric encryption, a different set of keys is used to encrypt and decrypt the data. This key pair is a combination of a public and private key. A public key is used to encrypt the data, whereas a private key is used to decrypt the data. A public key goes along with the data over the internet, but a private key remains with the individuals who are using it, shown as follows:

 

 

 

                            

The public and private key pair consist of two uniquely related cryptographic keys. Here is an example of a public key:

3048 0241 00C9 18FA  CF8D EB2D EFD5 FD37 89B9 E069 EA97 FC20

5E35 F577 EE31 C4FB  C6E4 4811 7D86 BC8F BAFA 362F 922B F01B
2F40 C744 2654 C0DD  2881 D673 CA2B 4003 C266 E2CD CB02 0301
0001

A public key is made available to everyone through the internet and is stored in an accessible repository or directory. On the other hand, the private key must remain private to its owner; hence, it is also named a secret key.

Both public key and secret key are mathematically connected with each other; hence, data encrypted with a public key can only be decrypted by the respective secret key.

 

Certificate

A certificate is an electronic ID that represents the identity of a user or a device interested in communicating over a network. The certificate basically ensures that only a legitimate user can connect to the network. A certificate is generated by signing the public key by a trusted third party, that is, the CA.

The following are the three main types of certificates:

• Secure Socket Layer (SSL) certificate: SSL server certificates are installed on server hosting services, such as a web application, mail server, directory, or LDAP server. This certificate contains identifying information about the organization that owns the application. SSL certificates also contain a system public key. The subject of the certificate matches the hostname of the server. This certificate has to be signed by a trusted certificate authority. The primary hostname is listed as the Common Name in the subject field of the certificate.
• Client certificate: Client certificates are used to identify an internet user, a device, a gateway, or any other type of device. It is a digital credential that validates the identity of the client who owns the certificate. Today, many applications allow using certificates to authenticate users for a specific resource instead of a username and a password. Two users communicating over email will also use a client certificate to authenticate their respective identities.
• Code signing certificate: Code signing certificates are used to sign software running on the system. With millions of applications being downloaded by a user machine, it is important to verify the code; code signing certificates play an important role in this.
• Email certificate: The sender needs to identify which public key to use for any given recipient with the S/MIME protocol. The sender gets this information from an email certificate. Usually, the S/MIME protocol is used when email communication is deployed within the organization and with its own CA.

 

Certificate Authority (CA)

The CA is a trusted third-party that certifies that users, servers, databases, and administrators are who they say they are. The CA checks the credentials of users and grants the certificate, signing it with a secret key. The CA can be an on-premises solution or it can be a managed solution that offers certificate services, illustrated as follows:

 

The functions of the CA are as follows:

• Issuing and delivering certificates
• Posting certificates and a certificate revocation list (CRL) to repositories 
• Managing revocation requests from a certificate owner

In the following screenshot, we can see the list of digital signatures in a client system. There is a list of certificates from several certificate authorities with their expiry dates:

 

The different types of CA are as follows:

• Public digital certificate authority: There are several public certificate providers who manage the certificates used for commercial and personal purposes. Credentials are issued only after a specific fee is paid.
• Private digital certificate authority: Organization administrators can issue certificates to internal systems and users within the domain. A Windows server can create and store key pairs, but these private certificates won't be valid for outside communication.

Registration Authority (RA)

The RA is responsible for authenticating the identity of newer entities that require a certificate from the certificate authority. It also maintains local registration data information and initiates the renewal and revocation process for old certificates.

The functions of the RA are as follows and are illustrated in the subsequent diagram:

• It is responsible for the authentication of new users or systems that require certificates from CAs
• It also performs some of the functions of the CA
•  It acts as an agent to the CA
• It maintains local registration data from the renewal and revocation of redundant certificates:

 

 

Certificate Repository (CR)

The CR is a certificate database that is accessible by all nodes in the PKI environment. It also holds certificate revocation-related information and the governing policy information. Certificate revocation lists are used in this repository to get an updated list of certificates.

The functions of the certificate repository are as follows:

• It allows information retrieval in an unauthenticated manner
• It acts as a database to hold information such as public key certificates, revocation lists, and policies

 

Architecture

The entire PKI architecture works on a model named the chain of trust. This model lies within the trust relationship between each identity. Specifically, the difference between a two-tier hierarchy and three-tier hierarchy is that the second tier is placed between the root CA and the issuing CA. The main reason for using a second-tier CA is to have a policy CA that is responsible for issuing certificates to the issuing CA; however, a three tier hierarchy provides better security. This policy CA can also be used as an administrative boundary. This design is also useful if the administrator needs to revoke a number of CAs due to a key compromise; the revoke can be performed at the second level, leaving other branches of the root available, as shown in the following diagram:

 

 

During the signing process, the root CA digitally signs the intermediate certificate using its secret key. This process achieves authenticity, stating that the intermediate certificate is trusted by the root CA. Each CA can receive the certificate request from the client and issue it. Normally, the root CA can't be reached by the client, but the client is eligible to hold the root CA certificates. The client sends the certificate request to some subordinate CAs and gets the certificate installed, as shown in the following diagram:

 

 

In the following diagram, we can see the flow of sharing digital certificates and their decryption. In order to authenticate the party, the digital certificate is decrypted using the public key:

 

 

After understanding the hierarchy of digital certificates with identity, intermediate, and root certificate authorities, now we will learn how communication is established and processed between end clients with browsers and SSL websites. A client requests to access the HTTPS website. A client's browser is preloaded with a number of root CA certificates. Consider the steps as follows:

• The client connects to the SSL website.
• The website responds to the client with its identity and intermediate certificates.
• The client then confirms the identity of the intermediate certificate by decrypting the digital signature using the intermediate public key.
• The client then confirms that the requested URL matches a distinguished name within the identity certificate. If there is a mismatch, it displays a warning.
• Traffic then gets encrypted/decrypted by the client using a public key and by the server using a secret key.

 

Certificate Life Cycle

As per the National Institute of Standards and Technology (NIST), the encryption key life cycle is a combination of the pre-operational, operational, post-operational, and deletion stages of key management. It is important to consider the time spent in the account as the validity of a key is always limited. Hence, the crypto period is used to record the time during which a specific key is authorized for use. The crypto period is determined by combining the estimated time during which the encryption will be applicable and the time when it will be decrypted for use, illustrated as follows:

 

 

The following diagram shows the crypto period flowchart with multiple keys:

 

 

Now, we can examine the stages in which a key is used and processed:

• Key creation: The encryption key is generated and stored on the key management server. The key manager generates the encryption key pair through the process of cryptography by using a secure random bit generator. Once the key pair is created, it is then stored with all its attributes in the key storage database. The attributes usually consist of name, size, instance, activation date, rollover, mirroring, key access, and other related attributes. The key activation time can be scheduled, or it can be activated the moment it was created. The encryption key manager keeps track of current and past instances of the encryption key.
  
• Key use and rollover: The key manager is responsible for allowing authorized users or the system to retrieve information and also allowing them to process encryption or decryption. It is also responsible for managing the state of an encryption key throughout its lifetime and over every instance. If an organization has a policy that states it should use a new set of keys every year, then the key manager should retain previous versions of the key and dispense only the current version. However, previous versions can still be retrieved in order to perform the decryption process.
• Key revocation: An administrator connects to a key manager to revoke a key so that it is no longer used for further encryption and decryption processes. If required, the administrator can even reactivate the key and use it for further steps. There are some situations where the administrator can also use the decrypted data that was previously encrypted, such as an old backup. The encryption life cycle is illustrated as follows:

 

 

• Back up (escrow): The NIST recommends an archive for all deactivated keys. This archive has to be protected from any unauthorized modification, deletion, and alteration. It is also recommended that it has a recoverable key mechanism after the end of its crypto period.
  
• Key deletion (destruction): If the key is compromised or is not being used for a long period of time, the administrator should choose to delete the key from the key storage database of the encryption key manager. The key manager removes the key and all of its associated instances, or it can specifically remove certain instances. This option plays an important role when the data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure and unrecoverable because it is impossible to recreate the encryption key.

 

Key Management

The Key Management Interoperability Protocol (KMIP) is used for communication between clients and servers to perform management operations on stored objects, which are maintained by a key management system. This is a standardized way to manage encryption keys throughout their life cycle and it has been developed to facilitate both symmetric and asymmetric cryptographic keys, digital certificates, and other related templates to streamline object creation and management, illustrated as follows:

 

Under the guidelines of the Organization for the Advancement of Structured Information Standards (OASIS), a nonprofit consortium that provides standards for people to exchange information over the internet and within their organizations, there are certain lists of objects a client can request to the key management server:

• Create a key or a key pair: This is used to generate a new symmetric key or a new public/secret key pair and register new, managed cryptographic objects
• Register: It is mainly used to register a managed object with keys, passwords, or some other cryptographic materials
• Re-key: In order to generate a replacement key, also called a key change, re-key is used for existing symmetric keys or key pairs for an existing public/private key pair
• Derive key: In order to derive a symmetric key or secret object, a derive key is used to fetch the data objects that are already known to the key management system
• Locate: In order to find one or more managed objects, a locate request is used for attributes specified in the request
• Check: This is used to check for the use of a managed object, as per the value specified in the request
• Get or get attributes: This is used to return a managed object specified by its unique identifier, or more than one attributes associated with a managed object
• Add, modify, or delete attributes: These are used to add, delete, or modify an attribute instance associated with a managed object
• Activate: This is used to activate a managed cryptographic object
• Revoke: This is used to revoke a managed cryptographic object
• Destroy: This is used when you are required to destroy a key for a specific managed object
• Archive: This is used to specify a managed object
• Recover: This is used to get access to a data recovery process

 

Challenges of the existing PKI model

The challenges of the existing PKI model are as follows:

• Problem 1 – the need for additional security: According to a report from the Ponemon Institute's 2016 research, 62% of businesses have deployed cloud-based applications using PKI, with an increase of 50% in 2015. If the central certificate repository gets compromised, it will lead to a massive data breach and account theft. Organizations tend to use an additional layer of security such as Hardware Security Modules (HSMs) to secure their PKIs. HSMs are deployed to protect PKIs for the most critical root and for issuing CA private keys. Organizations are opting for multi-factor authentication for administrators and HSM use.
• Problem 2 – central authority: In the current state of the internet, a central authority (root authority) is responsible for managing DNS requests and responses (root authority), X.509 certificates, and much more. Therefore, all internet-connected devices and systems have to trust the third party to manage public keys and identifiers. Let's take an example of a domain name; even though it has been purchased by its owner, it practically belongs to third parties, such as the Internet Corporation for Assigned Names and Numbers (ICANN), domain registrars, and certificate authorities.

Furthermore, these trusted third parties are very much capable of intercepting and compromising the integrity and security of users worldwide. There have been several cases where these trusted third parties have shared their customer's information to security agencies and other bodies. They can either do this for financial gain or to prepare customer behavior analytics.

 

How can blockchain help?

PKI has major vulnerability because of its centralized management system. Blockchain, however, is fundamentally decentralized and allow communication between several parties without any third-party involvement. The approach of going decentralized can be a paradigm shift in the PKI; therefore, it needs a systematic approach to deploy it.

 

Decentralized infrastructure

Blockchain is about achieving a decentralized network of multiple participants without third-party involvement. A Decentralized Public Key Infrastructure (DPKI) is an innovative concept that creates authentication systems over public systems without depending on a single third party that can compromise the integrity and security of the system. As we already know, blockchain is built with a trustless approach that allows both trusted and untrusted parties to communicate with each other. However, trust is usually established among geographically and politically disparate participants with several consensus models for the state of the ledger. By definition, blockchain allows you to store any kind of value with several nodes in the network. With DPKI, this value will be a form of secret property.

A principal can be given direct control over global readable identifiers, such as a website domain, by registering the identifier in the blockchain. With the key-value database, the principal uses the identifier as the lookup key. Blockchain can allow the assignment of confidential assets, such as public keys and other attributes, and permit these values to be globally readable in a secure manner that can't be compromised by any MITM, which is possible in PKIX. This is accomplished by allowing the most correct public key to link with the identifier value, and authentication is performed by an identifier lookup of the latest public key.

In this design of DPKI, the system remains decentralized, and control over the identifier remains with the principal. This eliminates the risk of the identifier data store getting compromised.

 

Deployment method

Ethereum is one of the most flexible and reliable blockchains. It is a programmable blockchain and fits with a granular and policy-based PKI. The PKI is implemented as a function in a smart contract in an Ethereum blockchain. Each entity can have multiple attributes to authenticate ownership. This entity can be a public key or an Ethereum address. Each transaction is identified using a public key and then represented by a corresponding entity ID and PKI. A smart contract is used to program the events and functions of various operations in the PKI. The smart contract can also be configured to invoke specific PKI operations such as create, derive, remove, destroy, and many more. These functions and processes will be written in Solidity and deployed in EVM, which will deliver easier user management for PKI operations. The following sets of PKI operations are made available by programming a smart contract:

• The registration of an entity: Users or systems are added to the PKI system by calling a registration event from the smart contract. The entity can be as simple as an Ethereum address, public key, attribute ID, data, and data hashes. The configured event on the smart contract collects the entity and forwards it as a transaction to Ethereum. The queued transactions are mined, and a block is created that will later be added to the blockchain.
• The signing of attributes: An entity can be characterized using a registration event. Each attribute of the entity can be signed by the PKI system through a smart contract, and a transaction will be issued. This signed entity will later be made available to other entities or users.
• The retrieval of attributes: The attributes of the entities can be located by applying a filter to the blockchain using the respective IDs of events that have been configured on the smart contract.
• Revoke signature: This is one of the most critical functions required by any PKI solution: to revoke the digital signature on attributes or entities. Revocation becomes extremely important when a user loses his/her key or it is compromised. Smart contracts can be configured to invoke the revocation event and revoke the signature on a specific entity.

 

Requirements

In the DPKI deployment, the registrar still has a role in the infrastructure, but it is restricted as follows to ensure that the identities of entities are represented in the network:

• It is required to ensure that software is always under the control of principals and corresponding keys.
• Private keys have to be generated in a decentralized way to ensure that they remain under the control of the principal. The generation of a key pair on behalf of a principal has to be strictly prohibited.
• There has to be no single entity that can change other entities without consent from the principal.
• Once a namespace is created within a blockchain through an Ethereum smart contract, it can't be destroyed.
• The registration and renewal of identifiers has to be transparent.
• By default, software that manages identifiers must ensure that all activities such as creating, updating, renewing, or deleting identifiers is forwarded through a decentralized mechanism.

This article is written in collaboration with Raj Gupta who has CISA, CPISI, Cobit 5, ISMS LA, CDPO-GDPR, CEH, and CHFI certifications. He is also the author of Hands-on Cybersecurty with Blockchain book.

What is Next

If you are interested in exploring more complex yet novel topics on blockchain security, you can read our below articles. If you are new to blockchain technology, taking our Intro to Blockchain Technology (self-paced) course is highly recommended.  

• Blockchain-Based DNS Security Platform
• Deploying Blockchain-Based DDoS Protection

Resources

Resources- Free Webinars on Blockchain

Here is the list of our free webinars that are highly recommended:

• Hyperledger Fabric for system admin versus developers
• How to harness blockchain for environmental and corporate sustainability
• Review of Initial Coin Offering, Security Token Offering and asset tokenization use cases and best practices
• Blockchain for entrepreneurship- 27 blockchain business use cases
• Hyperledger Fabric for entrepreneurship- 21 blockchain business use cases

Resources- Free Courses

Here is the list of our 10 free self-paced courses that are highly recommended:

• IT Career Roadmap Explained
• Web Design with Bootstrap
• User Experience Best Practices
• Intro to Search Engine Optimization
• Web Design with WordPress
• Introduction to Drupal CMS
• Intro to Joomla CMS
• Intro to Cybersecurity
• Introduction to Cloud Technology
• Recorded Live Webinars and Classes

Resources- Self-Paced Blockchain Courses

If you like to learn more about Hyperledger Fabric, Hyperledger Sawtooth, Ethereum or Corda, taking the following self-paced classes is highly recommended:

1. Intro to Blockchain Technology
2. Blockchain Management in Hyperledger for System Admins
3. Hyperledger Fabric for Developers
4. Intro to Blockchain Cybersecurity
5. Learn Solidity Programming by Examples
6. Introduction to Ethereum Blockchain Development
7. Learn Blockchain Dev with Corda R3
8. Intro to Hyperledger Sawtooth for System Admins

Resources- Live Blockchain Courses

If you want to master Hyperledger Fabric, Ethereum or Corda, taking the following live classes is highly recommended:

• Live and self-paced blockchain development with Ethereum
• Live and self-paced blockchain development with Hyperledger Fabric
• Live and self-paced blockchain development with Corda
• Immersive Blockchain Bootcamp with live and self-paced courses
• Live crash course for learning Ethereum with Solidity
• Live crash course for building DApps with Hyperledger Fabric 
• Live crash course for building DApps with Corda
• Live full-stack blockchain development in Hyperledger and Ethereum

 

Resources- Articles and Tutorials on Blockchain Technology

If you like to learn more about blockchain, reading the following articles and tutorials is highly recommended:

•  History and Evolution of Blockchain Technology from Bitcoin
•  Overview of Blockchain evolution and phases from Ethereum to Hyperledger  
• Comprehensive overview and analysis of blockchain use cases in many industries
• Comprehensive Blockchain Ethereum Developer Guide from Beginner to Advance Level
•  How to Write Ethereum Smart Contracts with Solidity in 1 hour
•  Intro to Hyperledger Family and Hyperledger Blockchain Ecosystem
• Essential Hyperledger Sawtooth Features for Enterprise Blockchain Developers
• Blockchain Developer Guide- How to Install Hyperledger Fabric on AWS
• Blockchain Developer Guide- How to Install and work with Hyperledger Sawtooth
• Blockchain Developer Guide- How to Install Hyperledger Burrow on AWS
• Blockchain Developer Guide- How to Install Hyperledger Iroha on AWS
• Blockchain Developer Guide- How to Install Hyperledger Indy and Indy CLI on AWS
• Blockchain Developer Guide- How to Install Hyperledger Seth and Docker on AWS
• Blockchain Developer Guide- How to Configure Hyperledger Sawtooth Validator and REST API on AWS
• Blockchain Developer Guide- How to Build Transaction Processor as a Service and Python Egg for Hyperledger Sawtooth
• Blockchain Developer Guide- How to Deploy Ethereum Smart Contracts with Hyperledger Burrow
• Blockchain Developer Guide- How to Create Cryptocurrency Using Hyperledger Iroha CLI
• Blockchain Developer Guide- How to Explore Hyperledger Indy Command Line Interface
• Blockchain Developer Guide- Comprehensive Blockchain Hyperledger Developer Guide from Beginner to Advance Level