Hybrid Approach for Certificate Verification using Blockchain in Cloud Environment

doi:10.21203/rs.3.rs-2578190/v1

Download PDF

Research Article

Hybrid Approach for Certificate Verification using Blockchain in Cloud Environment

https://doi.org/10.21203/rs.3.rs-2578190/v1

This work is licensed under a CC BY 4.0 License

You are reading this latest preprint version

The current analog system for managing educational certificates was unreliable and slow. Students have to request their official transcripts from their university registrar and pay their fees for each copy of the transcript requested. The person who has acquired the credentials should be in charge of them, but most of the time the students have to rely on third parties, such as universities or employers to store, verify and validate the credentials. Employers and universities still at times need to call the issuing authority of the certificate if they want to be sure that the transcript was not faked. It’s complicated and tedious, which is one of the major factors for fraud. Making certificates easily verifiable and transferable is one advantage of digital systems. There are several advantages of creating a digital infrastructure for certificates, but the stakes are high as such systems will grow forward to represent our professional reputations. When proposing a digital method of processing certificates, the elimination of counterfeit certificates from the system should be given top priority. Using a hash-based storage method to assure the authenticity and security of digital content kept on the platform, colleges can submit student certificates and authenticate certificates from other member universities. A permissioned blockchain-based system is employed in the proposed system for the safe verification of academic degrees. The Raft ordering service is used to handle numerous distributed orderers. Universities can upload their student's credentials and validate the certifications of other member universities. A hash-based storage system is used to store the digital contents of the certificate in order to guarantee its authenticity and security. The certificate will be hashed using the SHA-256 technique, then stored in a blockchain. The student can use this hash value to further verify their certificate. The university's reputation is determined using the Beta Reputation Algorithm. This is done in order to avoid or remove the network organization that helps phoney certificates or fake validation. The system can be accessed from any location in the globe if it is set up in a cloud environment.

Blockchain

Digital Certificate

Verification

Raft

Blockchain is a distributed database that is frequently used to record specific transactions. A square that as of now has records of a few exchanges gets expanded when an agreement is achieved among multiple hubs. The hash value of each square's most recent partner is stored there for the association. Each square has a connection to the others, and they all come together to make a blockchain. Since information is scattered among various centers, decentralization results from this dispersed information stockpiling. A student must generate all of his credentials at each level for acceptance [1]. There is a risk of losing and damaging the certificate. It is also tedious for the validator to confirm each testimony. With such a large population, our country annually graduates 26.3 million students. It is incredibly difficult to maintain track of and approve such a large number of records. As a result, an undesirable circumstance arises, such as the changing and manufacturing of a false or duplicate certificate [2]. Recognizing a fake and a unique certificate will need a lot of concentration and time. In Blockchain, information or a node is accepted only when a large number of people agree on it. The next issue that comes to mind is the time utilization for approval. The framework that is built will not only approve testaments but will also construct authentications [3][4][5]. Following the successful verification of certificates based on the public blockchain Ethereum, the next level of verification system based on Hyper-ledger Fabric is built [6]. The original files are stored in a decentralized P2P network using IPFS. The ledger just stores the file's hash value. Transactions in Hyper-ledger are submitted using an interface to the RAFT ordering service. Blockchain can accept a basic part of the educational region by extending the insurance, security, and interoperability of the enlightening data. It holds the possibility to address numerous interoperability challenges in the area and empower the secure sharing of information among the different elements and individuals associated with the interaction.

Employers and institutions must occasionally contact the certificate's granting authorities to ensure that the transcript was not forged. It's difficult and time-consuming, which is one of the main reasons for fraud. Students must request official records from the college's enrollment centers and pay fees for each copy of the document stated. One advantage of digital systems is that certificates can be quickly verified and transferred. There are several advantages of creating a digital infrastructure for certificates [7], but the stakes are high as such systems will grow forward to represent our professional reputations. Using a centralized database, poorly formatted queries, and overly general queries can introduce slowdowns.

Relational databases are typically designed to run on a single server and scaling requires more complex and powerful hardware. There are several advantages of creating a digital infrastructure for certificates, but the stakes are high as such systems will grow forward to represent our professional reputations. Making a digital infrastructure for certificates has a number of benefits, but the stakes are high because these systems will eventually come to stand in for our personal and professional reputations. When using a centralized database, slowdowns might be brought on by improperly structured and overly generic queries. Most relational databases are created to function on a single server and scaling calls for more sophisticated and potent technology [8–9].

Here proposed a Hyperledger-based blockchain system for secure verification of academic certificates. IPFS is used to store the original files in a distributed P2P network. Only the hash value of the file is stored in the ledger. In Hyperledger, transactions are submitted via an interface to the RAFT ordering service. This service collects transactions based on the consensus algorithm and configuration policy, which may define a time limit or specify the number of transactions allowed. Beneficiaries will only see the details of the certificate once it’s been issued. Access levels can be customized as per requirement, so students won’t be able to change certificates. The performance measurements were computed by putting the consensus algorithms RAFT and PAXOS into practice. Based on a calculation of the university's reputation, the institution will either be added to or removed from the network. The use of the cloud to store data and verify certificates has replaced many data centers. The purpose of this research is to create a safe digital infrastructure that makes the transfer and verification of certificates simple. Universities can upload and transact certificates directly through the system. The ability to access it from anywhere in the globe is made possible by sending it to a cloud environment.

The four essential services, including privacy, identification, confidentiality, and verification, were the focus of the verification Privacy Control Protocol (VPC). In a decentralized network, only administrators have the ability to issue certificates on the network. Additionally, the user's input to the design is limited to the control of certificate locking and unlocking using paper contracts; as a result, only students have control over privacy. No entity can issue educational certificates except for those entities added by Ministries. It is also ensured that only authorized universities can issue educational certificates, eliminating any fraudulent issuance by shady parties or unauthorized entities. This also allows for easy verification of certifications. Certificates issued by universities should be private to those universities unless their owners decide otherwise. The presented protocol allows full control over entities to exist within the network.

The college must first sign up in order to create unchangeable certificates based on blockchain technology. Each college will have a wallet address that it will use to send the exchange. Only the owner of the smart contract has the ability to add a college. Every made statement will be stored in the Interplanetary Document Framework (IPFS), which will thereafter return the unique hash generated using SHA-256 computation. This will serve as each archive's own personality [10].

A distributed document architecture called the Interplanetary File System (IPFS) aims to decentralize the web and make it faster and more efficient. It combines key innovations like Bit Torrent and Git to create numerous registering frameworks for data sharing. IPFS has experienced amazing improvements and support from both people and endeavor associations since its introduction in 2016 [11][12]. The fact that IPFS is designed to function on top of other conventions, including FTP and HTTP, partially explains the rapid adoption of this distributed document system. When dealing with large files that may take a long time to upload or that demand a high transfer speed when downloading, IPFS performs well.

To prevent fake declarations, the researchers [13] developed software. Because of the absence of an anti-forge mechanism, the certificate is to be forged. Thus, it was intended for the decentralized application to utilize Ethereum blockchain technology. They initially created a digital certificate for a paper-based certificate, and at that point, the hash value created for that specific certificate was tossed into the blockchain framework. The framework reduces the cost of paper and gets rid of fraudulent certificates. A blockchain-based authentication framework was developed [14]. In this framework, the authentication authority or Certificate Authority (CA) marked the authentication and the renouncement status data of the regarded authentications are distributed by the subject (Certificate Authority). The activity of the Certificate Authority is monitored using public logs. This framework was implemented using Nogix and Firefox. This system established confidence, but the delayed approval of certificates creates a misleading impression of security [15][16].

The authors [17] used the Hyper record Fabric blockchain stage. In this system, the Certificate Authority (CA) simply obtains the certificate from the domain owner using Google's Certificate Transparency (CT) method. They aim to prevent SSL/TLS CA from giving a certificate for a domain without being apparent to the proprietor of the area. This system also experienced low adaptability and less exchange.

The Verification Privacy control protocol (VPC) aimed to maintain four key services: privacy, authentication, confidentiality, and verification. Only administrators can issue certificates on the network in a decentralized solution, or in a decentralized network. And the user's contribution is limited to the control of certificate locking and unlocking through paper contracts mentioned in the design, hence the privacy control is only controlled by the students. Only authorized universities can issue educational certificates, eliminating any fraudulent issuance by shady parties or unauthorized entities. This also allows for easy verification of certifications.

Employers and universities still at times need to call the issuing authority of the certificate if they want to be sure that the transcript was not faked. It’s complicated and tedious, which is one of the major factors for fraud. Students need to demand official records from the college’s enlistment centres and pay charges for each duplicate of the record mentioned. Making certificates easily verifiable and transferable is one advantage of digital systems. There are several advantages of creating a digital infrastructure for certificates, but the stakes are high as such systems will grow forward to represent our professional reputations. Using a centralized database, poorly formatted queries, and overly general queries can introduce slowdowns. Relational databases are typically designed to run on a single server and scaling requires more complex and powerful hardware. Recognizing a fake and a unique certificate will require a great deal of focus and result in a waste of valuable time.

Students must ask for official documents from the college's registration offices and pay fees for each copy of the record requested. Employers and institutions still occasionally need to contact the organization that issued the certificate to confirm that the transcript was authentic. There is a need for a secure digital system that provides a hassle-free experience in transferring and verifying the certificate. Universities can upload certificates and transact with them directly through the system. However, students who possess a digital copy of their certificates can simply have that copy confirmed by other universities while still maintaining the security and legitimacy of the document. The system can be accessed from anywhere in the globe by deploying it in a cloud environment. The architectural diagram of the proposed system is presented in Fig. 1.

Figure 1 Proposed certificate verification system

4.1. Web Server

A two-way verification system is developed to authenticate the university. By preventing man-in-the-middle attacks, this two-way authentication mechanism provides security. The universities can now grant certifications after joining the network. In this case, the university must log in and validate its credentials. Following the verification, the student's information must be entered in order to create the digital certificate using the web server interface. The web server in Fig. 2 acts as an interface between the user and the blockchain mechanism. A certificate can be uploaded to the blockchain network, and the user can receive the resulting hash value. IPFS is used to fetch and store the certificates in the distributed file system.

4.2.Certificate Verification

Universities can now obtain the certificate from the interplanetary file system and verify it. The hash value provided by the user is entered once the verifier has been authenticated. If the submitted hash value is present in the ledger or if the certificate is valid, that hash value will return the document; otherwise, a prompt stating that "no such certificate exists" is displayed to indicate the absence of the files. The process of certificate verification is shown in Fig. 3.

4.3. Raft Consensus

Raft is a calculation that comes to an agreement when dealing with a fake log. Raft uses a "pioneer and supporter" business model, where a channel-specific pioneer hub is selected, and the devotee imitates that hub's decisions. The logs are guaranteed to hold similar information if two passages in different logs (the Leader's and Followers') have an identical list and term, and the logs are identical up to that Index. In the unlikely event that the Leader crashes, the logs can start to disagree. So, there is a leader election. The logs are guaranteed to store the same data and to be identical up to that Index if two entries in distinct logs (the Leader's and Followers') have the same index and term. The process involved in Raft Consensus is shown in Fig. 4.

Figure 4 RAFT consensus

Algorithm 1: Leader Election Algorithm in Raft

Input: List of Orderers

Output: Elected Orderer

N ← total number of orderers in the fabric network

T ← array(N)

for i ← 1 to N do

T[i] = 0 ;

end

/* N must be a minimum of 3 for the election to happen. Each node votes to either itself or some other nodes */

for each node i in N nodes do

T[x] = T[x] + 1; // 1 ≤ x ≤ N end /* finding the maximum count of vote */

max vote = 0; for i ← 1 to N do

max vote = (max vote, T [i]) end;

4.4. Inter-Planetary File System

The Inter-Planetary File System (IPFS) is a convention and shared organization for sharing information in a distributed file system framework. IPFS uses content-addressing to specifically identify each document in a global namespace bridging all calculating devices. During certificate verification, IPFS is used to fetch and store the certificates in the distributed file system. In order to provide a robust system for file storage and sharing, IPFS is built around a decentralized system of client administrators that each holds a portion of the general information. Different peers within the organization can locate and request specific content from any hub by using a distributed hash table (DHT), and any client within the

Algorithm 2: Inter-Planetary File System

IPFS Document Upload

Input: Document upload

Output: Hash Value

Step 1: If it is a bulk uploading of certificates goto Step 2 else goto Step 4.

Step 2: Separate Each file. Ref (Web server Module)

Step 3: Foreach certificate uploaded do Break the file into blocks each of size 256kb. We’ll get (N/256) blocks. Where N is the size of the document in kb. End

Step 4: Height = 0;

Step 5: i = 0; j = 0; while i ≤ N do block[height + 1][j] = hash(block[height][i],block[height][i + 1]) /* where hash is sha-256 hash function. */ Height = Height + 1; N = N/2; i + 2; j++; end

Step 6: Repeat Step 6 until N = 1; Now row value is the height of the tree.

Step 7: lock[row][0] represents the hash value of the root element, which is the hash value of the file.

IPFS Document Fetch

Input: Hash of the File.

Output: Valid or Not Valid.

Step 1: Find any peer x such that it is directly connected and accessible to the network.

Step 2: Search if peer x has the certificate (whose certificate ID is denoted as “E”)

Step 3: If x has the certificate fetch the document and END.

Step 4: If the hash table at x has the location of the document, then goto Step 5 else goto Step 6.

Step 5: Go to the new location and fetch the document and END.

Step 6: Find the nearest neighbor node y whose hash table may contain the location of E. y = NULL;

organization can serve a document by its content address. Figure 5 explains the steps involved in IPFS.

4.5. Hash Value Generation

Each university will be having its wallet address from which it is going to send the transaction. University can be added only by the owner of the smart contract. The university can access the system and can create certificates with data fields. Each created certificate will be stored in the Interplanetary file system (IPFS) which in turn will return the unique hash generated using the SHA-256 algorithm. This will serve as a unique identity for each document. The generated hash and detail of certificates will be stored in the blockchain and the resultant transaction id will be sent to the student. This transaction id can be used to verify the certificate details and can view the original copy of the certificate using the IPFS hash stored along with the data.

4.6. Hyper-ledger Fabric Transaction

A crucial component of the hyper-ledger fabric network is the transaction. The certificates uploaded to the fabric network are reflected in the transaction. The client transmits a transaction proposal to the designated orderers, which are endorsing peer nodes. Orderers run the chain code in accordance with the information stated in the proposal and in the world state after verifying the client is authorized to transmit a transaction proposal. Following the execution, they send the customer the proposal response. In Fig. 6, the hyper-ledger fabric transaction process is pictorially presented.

Algorithm 3: Hyper-ledger Fabric Channel Creation

Step 1: Generate the Crypto artifacts using the cryptogen tool we define the configtx.yaml file which contains the configuration of the channel such as anchor peers, and members.

# cryptogen generate −−config=. / crypto − config.yaml

Step 2: Generate the genesis block using the command.

# Configtxgen − profile $PROFILE NAME − output Block ./channel − artifact s/genes is .block

Step 3: Generate the channel artifacts

# configtxgen − profile $PROFILE NAME − output Create Channel Tx./channel − artifacts/channel.t x − channel ID $CHANNEL NAME

Step 4: Generate the transaction for the Anchor Peer in each Peer Organizations. configtxgen − profile

$PROFILE NAME − output Anchor Peers Update. / channel − artifacts / Org1MSPanchors .tx − channel ID $CHANNEL NAME − asOrg Org1MSP\\

4.7. Organization Inclusion and Deletion

As shown in Fig. 7, an organization is added when it needs to add the certificates and verify the certificates issued by other members of the system. For a successful inclusion in the system, a university has to pass the two-factor authentication and a manual verification by the admin. Upon verification, an org key is assigned to that university by the membership provider (MSP) and it is stored in the web server.

Using the org key universities can access their peers thereby being able to use the functions of the system. A university needs to be removed from the system when it misuses the system by uploading an invalid certificate. So, a beta reputation function is proposed used to increase or decrease the reputation of the universities based on the feedback received. If the reputation value of the university falls below a threshold value ( -0.5), it is removed from the system and all its certificate statuses are changed to be invalid.

Algorithm 4: Organization Inclusion and Deletion

Input : Credentials of the organization.

Output : Successful addition of the organization to the hyperledger fabric network

Step 1 : Get the organizational credentials through the web interface. Univ name, phone number, user id (email), location.

Step 2 : Registering the university has to pass the captcha check (captcha generation algorithm in web server module).

Step 3 : The system admin should grant access to the university based on the details provided.

Step 4 : Check if University already has a key. If the key already exists, end the process prompting that the university already exists.

Step 5 : Create a new Gateway for adding the university.

Step 6 : Get the identity of the admin.

Step 7 : Register the university as a client to the admin.

Step 8 : Enroll the university using the enrollment secret generated from Step 7

Step 9 : Create a user identity using the enrollment certificate and the enrollment secret key generated from the previous step (Step 8)

4.8. Feedback System

In order to tackle malicious users and counterfeit certificates, it is mandatory for a system to have a feedback system that accepts the feedback of the receiver and reputes the issuer based on the feedback received. Considering the system is a centralized one, the beta reputation system is implemented. The beta reputation system is based on beta probability density functions to combine feedback and derive reputation ratings. The advantage of the beta reputation system is flexibility and simplicity. The reputation change is directly dependent upon the reputation value of the university that gives the feedback. The higher the reputation, the greater will be the impact of the feedback given by that university. The process involved in the feedback system is presented in Fig. 8.

4.9. Cloud Deployment

Deployment in a cloud (Fig. 9) makes the system more secure and reduces the numerous local machines. It also reduces IT costs and also replaces data centers. This module consists of a hybrid cloud system that is private and public cloud where the public cloud can be used by business-to-consumer transactions and the private cloud will be used by business-to-business transactions. Cloud Deployment makes the framework safer and decreases the various nearby machines and lessens IT costs. It replaces the server farms situated in different spots.

The whole system of certificate verification got deployed in a cloud platform and it was built successfully. For the cloud platform, HEROKU is used. It is based on AWS and it provides Platform-as-a-Service (PaaS) for the users. When we load our data that is the whole system of the certificate verification process, the successful deployment message will be displayed. After an hour or a day, we receive an access address sent by the HEROKU cloud platform. Using that address we can access the system in a cloud environment.

The graph in Fig. 10, shows the time taken to process requests when the number of requests varies with the varying number of peers handling the request in the fabric system. The inference can be made from the graph that the average time taken for a peer to process a request (write request) varies between 225.6 ms to 269.6 ms. These analyses were performed based on the data collected by testing the fabric along with the node API server(backend)

Whenever the process of verification got over, the reputation value got calculated. It is fully based on the type of result it produced while doing the verification process. Whenever the user gives an invalid certificate, the reputation value becomes low. It just falls under the threshold value. When the user gives the invalid certificate, the reputation value becomes 0.

The performance of any system needs to be evaluated on certain criteria; these criteria then decide the basis of the performance of any system. Such parameters are known as performance metrics.

5.1. Throughput

Throughput refers to how much data can be manipulated through a given time frame. The data involves enrolling new data of a candidate or updating and retrieving data of the candidate. It can be measured either in bits per second or data per second.

Throughput = (Sum of Enrolling/Updating/Retrieving Data)

For the calculated values of throughput given the quantitative result and the observations. Let the X-axis be the number of peers who are all doing operations i.e., giving requests for fetching documents from the file system. Let Y be the time taken to process the particular request in seconds. As shown in Fig. 11, Here the three bar represents the number of requests given by one peer at a time. The blue color bar represents one request at a time and the orange bar represents requests that are > 1 and < 10 at a time. So, from the throughput, we can understand that the requests to process will take an average time that is greater than or equal to 0.9 secs.

5.2. Delay

Network delay is a design and performance characteristic of a network. It specifies the latency for a bit of data to travel across the networks. These delays can be calculated from receiving OTP, time taken for hosting connection, and time taken for data entry and retrieval.

Delay = Host connection delay + data transmission delay.

Let X represents the number of peers who are all giving requests to access the certificate from the file system and Y represent the time taken to process the request. In this graph, we can see the delay that happens whenever the peer increases by 1 unit. It increases by a time of 0.27 secs for each peer. It is normal for the system to get a delay of 0.25 seconds. It shows the peak increase of about 0.25 secs as an average as shown in Fig. 12.

5.3. Latency

Latency is the time between when the request is submitted and when the response is received.

Latency (L) = Time when the response is received–Time when the request is submitted.

When the value of EPR is a decimal, it is rounded off to the next natural number. For each successful transaction, a block is added to the ledger. Therefore, ledger height is directly proportional to the number of transactions successfully submitted to the network. Also, the greater the ledger size, the greater will be the latency value since the system needs to process a greater number of blocks as shown in Fig. 13.

5.4. Compromised host percentile

The Compromised host percentile (CHP) of the RAFT ordering system is defined as the minimum count of orderers that need to be in an available state to achieve the consensus of the ledger. The Compromised Host Percentile (CHP) of the system can be inferred from the HP as the minimum HP in which the system can achieve consensus. The following graph shows the number of available orderers vs the total number of orderers before a system crash.

Host Percentile (HP) = orderers assigned – orderers crashed/number of orderers assigned

The Capacity of the system to handle is directly proportional to the count of peers present in the system to handle requests. A single peer in a uni-peer setup can handle 5.8323 operations per second. As shown in Fig. 14, the number of peers increases the throughput increases and reaches a max of 37.613 operations which is considerably higher than bitcoin’s throughput which has an average of 8 transactions per second.

Students need to demand official records from college enlistment centers and pay charges for each duplicate of the record mentioned. Employers and universities still at times need to call the issuing authority of the certificate if they want to be sure that the transcript was not faked. A secure digital system that provides a hassle-free experience in transferring and verifying the certificate is built. Universities can directly interact with the system and can upload and transact the certificates. On the other hand, students have their own digital copies of their certificates which can be easily verified by other universities while preserving the security and authenticity of the certificate. This system has been designed to provide ease of use and scalability, using a permissioned blockchain to allow for faster processing times and a web application to provide a usable interface for users. Further works to improve our system would include additional automation by incorporating IoT like bar code sensors, scanners, etc., Using the IoT technology, we can easily scan the Certificate and send them to the cloud for verification and the result will be displayed to the user and the respective student. To fully eliminate the manual efforts and fully integrate with academic institutions’ information systems for minimal user interaction requirements. Deploying it in a cloud environment enables the system to access it anywhere in the world. The system can be further extended to investigate the possibility of security attacks on the system. The beta reputation function considers only two outcomes. Use of a different reputation function that considers multiple possible outcomes is advised in future work.

IPFS - Interplanetary File System
P2P - Peer to Peer
VPC - Verification Privacy Control Protocol
SHA - Secure Hash Algorithm
CA – Certificate Authority
HTTP – Hypertext Transfer Protocol
FTP – File Transfer Protocol
DHT – Distributed Hash Table
MSP – Membership Provider
PaaS – Platform as a Service
CHP – Compromised Host Percentile

Availability of data and materials

The data used to support the findings of this study are included within the article.

Competing interests

The authors declare that they have no conflicts of interest to report regarding the present study.

Funding

The authors received no specific funding for this study.

Authors' contributions

Author1 have made a substantial contribution to the concept and design of the article, the acquisition, analysis, and interpretation of data for the article; Author2 defined and drafted the article, revised it critically for important intellectual content and Author3 approved the version to be published.

Acknowledgements

Not Applicable

Rasool, S., Saleem, A., Iqbal, M., Dagiuklas, T., Mumtaz, S and Qayyum, Z. U. (2020). Docschain: Blockchain-Based IoT Solution for Verification of Degree Documents. IEEE Transactions on Computational Social Systems, vol. 7, no. 3, pp. 827-837.
Wen-Tao Zhu and Jingqiang Lin. (2016). Generating correlated digital certificates: Framework and applications. In the proceedings of IEEE transactions on information forensics and security, vol.11, pp.1117–1127.
Dalal Jignasha., Chaturvedi Meenal., Gandre Himani and Thombare Sanjana. (2020). Verification of Identity, and Educational Certificates of Students Using Biometric and Blockchain. Proceedings of the 3rd International Conference on Advances in Science & Technology (ICAST), Mumbai.
Cheng, N., Lee, C., and Chen, Y. (2018). Blockchain and smart contract for digital certificate. IEEE International Conference on Applied System Invention (ICASI), Chiba, Japan,pp.1046.
Jerina Gresch, Bruno Rodrigues, Eder Scheid, Salil Kanhere. S and Burkhard Stiller. (2019). The Proposal of a Blockchain-Based Architecture for Transparent Certificate Handling. Business Information Systems.
Tai-Hoon Kim, Gulshan Kumar, Rahul Saha and Mritunjay Kumar Rai. (2020). A Privacy-Preserving Distributed Ledger Framework for Global Human Resource Record Management: The Blockchain Aspect. IEEE Access, Vol.99.
Irawan Afrianto. (2019). Design and Implementation of Work Training Certificate Verification Based on Public-Blockchain Platform. IEEE Transaction.
Thangasamy, A., Sundan, B., and Govindaraj, L. (2021). Dynamic PHAD / AHAD Analysis for Network Intrusion Detection and Prevention System for Cloud Environment. 2021 4th International Conference on Computing and Communications Technologies (ICCCT), Chennai, pp. 273-279.
Govindaraj, L., Sundan, B., and Thangasamy, A. (2021). An Intrusion Detection and Prevention System for DDoS Attacks using a 2-Player Bayesian Game Theoretic Approach. 2021 4th International Conference on Computing and Communications Technologies (ICCCT), Chennai, pp. 319-324.
Imam, T., Arafat, Y., Alam, K. S. and Shahriyar, S. A.(2021). DOC-BLOCK: A Blockchain-Based Authentication System for Digital Documents, Third International Conference on Intelligent Communication Technologies and Virtual Mobile Networks (ICICV), pp. 1262-1267.
Coin market cap hyperledger arch wg paper1 consensus.pdf, accessed december (2019) https://www.hyperledger.org/wpcontent/uploads/2017/08/HyperLedger Arch WG Paper1 Consensus.pdf.
Afrianto, I., Heryanto, Y. A. (2020). Design and Implementation of Work Training Certificate Verification Based on Public Blockchain Platform, Fifth International Conference on Informatics and Computing (ICIC), pp.1-8.
Alrawais, A. Alhothaily, X. Cheng, C. Hu and J. Yu. (2018). SecureGuard: A Certificate Validation System in Public Key Infrastructure, IEEE Transactions on Vehicular Technology, vol. 67, no. 6, pp. 5399-5408.
Rama Reddy, T., Prasad Reddy, P.V.G.D., Srinivas, R. (2021). Proposing a reliable method of securing and verifying the credentials of graduates through blockchain, EURASIP J. on Info. Security, vol. 7.
Subalakshmi Mani, Bose Sundan, Anitha Thangasamy, and Logeswari Govindaraj. (2022). A New Intrusion Detection and Prevention System Using a Hybrid Deep Neural Network in Cloud Environment, Computer Networks, Big Data, and IoT. Lecture Notes on Data Engineering and Communications Technologies, vol. 117, pp.981-994.
Logeswari, G., Bose, S. and Anitha, T. (2022). An Intrusion Detection System for SDN Using Machine Learning, Intelligent Automation & Soft Computing, vol.35, pp.867- 880.
Li, H., and Han, D. (2019). EduRSS: A Blockchain-Based Educational Records Secure Storage and Sharing Scheme, IEEE Access, vol. 7, pp.179273-179289.

No competing interests reported.

Download PDF

Reviewers agreed at journal
09 Oct, 2023
Reviews received at journal
26 May, 2023
Reviewers agreed at journal
15 May, 2023
Reviewers agreed at journal
10 May, 2023
Reviewers agreed at journal
30 Apr, 2023
Reviewers invited by journal
03 Apr, 2023
Editor assigned by journal
17 Feb, 2023
Submission checks completed at journal
17 Feb, 2023
First submitted to journal
12 Feb, 2023

You are reading this latest preprint version

Hybrid Approach for Certificate Verification using Blockchain in Cloud Environment

Status:

Version 1

Abstract

Figures

1 Introduction

2 Related Work

3 Problem Statement And Objective

4 Proposed System

4.1. Web Server

4.3. Raft Consensus

4.4. Inter-Planetary File System

4.5. Hash Value Generation

4.6. Hyper-ledger Fabric Transaction

4.7. Organization Inclusion and Deletion

4.8. Feedback System

4.9. Cloud Deployment

5 Experimental Results

5.1. Throughput

5.2. Delay

5.3. Latency

5.4. Compromised host percentile

6 Conclusion And Future Work

Abbreviations

Declarations

References

Additional Declarations

Status:

Version 1