Journal of information and
communication convergence engineering
(J. Inf. Commun. Converg. Eng.)

Blockchain has brought a revolution in the realm of technology [1, 2] and has started to draw the interest of the stakeholders of a wide span of industries including finance, healthcare, and digital content distribution [3-8]. In blockchain, when a transaction occurs in the network, the transaction has to experience validation called a consensus mechanism, a process where some of the participants reach a mutual agreement in allowing that transaction [9]. Each block contains the hash of the previous block because of which it is called a blockchain [10]. In a blockchain, asymmetric cryptography is adopted to issue transactions [11, 12]. Internet of Things (IoT) has brought another revolution in the realm of technology [13-16]. Recently, IoT has established its mark in the education sector [17, 18]. Smart campuses, smart classrooms, digital content, and campus safety are some of the results of IoT. However, IoT technology is facing security risks. Entities in IoT need reliable and tamper-proof protection from attacks like denial-of-service. [19]. Blockchain can mitigate this issue with its security infrastructure [20, 21]. Examination is an important part of education [22, 23]. However, there is a threat, named question paper leaking (QPL), which can cause an unfairness issue during examinations. Nowadays, QPL is a serious issue throughout the world from university entrance examinations to public examinations, and the situation is worse in developing countries [24-27]. QPL can lead to some serious outcomes, such as quality of education being compromised and erosion of ethical standards [27]. Some more cases have been previously reported [28-47]. Although these cases [28-47] only cover the QPL incidents that occurred in 2017, some countries face this problem almost every year. Therefore, QPL occurs not only within developing and underdeveloped countries but also in developed countries. In QPL incidents, along with the students teachers and authorities can also be involved. Therefore, a smart examination system needs to be developed that can share examination papers securely without the concern of QPL. Moreover, social engineering, phishing etc., can loot anyone’s credentials to access data anytime. Therefore, examination management systems need more than user credential and random question selection. Question sharing (QS) should be performed through a more robust system, where user credential is less important. In this study, a blockchain-based smart and secured QS scheme (termed as BSSSQS) is proposed, a topic that has not been explored yet to the best of our knowledge. The major contributions of this study are as follows:

• • The proposed scheme can increase the security of questions and provide seamless QS sharing.

• • A two-phase encryption technique is proposed to provide security for question papers (QSPs).

• • A randomization algorithm is proposed for selecting QSPs before the exam.

• • The proposed scheme has been implemented, and the performance of the system has been analyzed.

The remaining sections of this paper are organized as follows: a discussion on existing works is presented in Section II. Section III illustrates the system model of BSSSQS. In Section IV, different transactions of BSSSQS are discussed in detail. A security analysis against different attacks is demonstrated in Section V. Section VI represents a discussion on performance analysis. Finally, Section VII draws the conclusions from this study.

To digitalize the examination system, different ideas have been shared previously [48-54]. In [48], three models of web examination system, such as B/S, C/S, and B/S combined with C/S, are discussed. Another web-based examination system was proposed for distant and formal education in [49]. In [50], an online examination system for PE theory courses was proposed, where every user uses a username and password to access the portal. In [51], an online examination system was proposed where MD5 encryption technique was exploited for security. An examination management system based on flat network was demonstrated by [52], which provides role-based security. In [53], a web-based examination system was proposed and integrated with existing learning management systems, whereas an online examination system based on TCP/IP client-server architecture was proposed in [54]. These systems mainly focus on system design and overall management. However, they could not guarantee to solve the QPL incidents.

We devised a blockchain-based QS scheme to make it secure and smart, as shown in Fig. 1. Four major entities are described in the subsections.

Figure 1. System model of the proposed BSSSQS

A. Question Setter (QUS)

In this entity, actors have to submit questions for the exam. They have a deadline for submitting questions. They can modify or delete questions before submitting. However, once they submit the question, they cannot change the questions anymore.

B. Question Cloud (QC)

This entity involves initial management of questions. After getting questions from the QUS, QC stores questions before sending it to the next entity. In this entity, questions are modified to prepare QSPs, where a QSP consists of a set of questions. Then, the QSPs are handed over to the next entity. This entity consists of seven modules. The functions of each module are summarized as follows. Question cloud manager (QCM): manages internal functionality; signature verifier (SV): verifies signatures of the requester; format question (FQ): formats and modifies the questions; question pool (QNP): stores modified questions; question filter (QF): sorts and makes sets; question queue (QQ): stores questions; and database (DB): contains information like signature and course.

C. BSSSQS Master (BSSSQS_master)

This entity holds the information of all the connected minions (nodes) to which it sends QSPs. This entity also maintains communication with its minions through a blockchain cloud. It also selects a QSP for the exam. Furthermore, this entity performs security mechanisms on QSPs. It comprises thirteen modules. The functions of each module are summarized here. Question queue (QNQ): stores QSPs temporarily; BSSSQS master manager (BMM): manages internal functionality; timestamp (TS): converts date to timestamp; question set (QS): organizes QSPs based on the course list; salt engine (SE): generates random data; data encryptor (DE): encrypts QSPs; encryption factory (EF): encrypts QSPs; hash generator (HG): generates hash of QSPs; contract generator (CG): generates a smart contract; database (DB): stores data of QSPs; guffy bot (GB): monitors internal tasks; question picker (QP): selects a QSP; and exclusion pool (EP): stores illegal QSPs.

D. BSSSQS Minion (BSSSQS_minion)

This entity contains processed QSPs in the blockchain. No one can access QSPs without experiencing smart contract, timestamp verification, etc. This entity consists of eight modules. The functions of each module are as follows: BSSSQS minion manager (BMNM): manages internal functionality; blockchain (BC): blockchain-based storage; minion bot (MB): monitors internal activity; smart contract manager (SCM): handles authorization requests and decrypts QSPs; database (DB): contains decrypted QSPs; user panel (UP): provides user interface and manages tasks; session manager (SM): contains information related to user activeness and authorization; and user authentication and authorization manager (UAAM): verifies user credentials.

In this section, we describe the different types of transactions performed in BSSSQS. The list of important notations with descriptions are summarized in Table 1.

Table 1 .

Notation	Description
η, ρ, Q	Nonce, Prime number, Question
τc, 𝕊h, QT	Timestamp, Salt hash, Questionnaire token
PW, ℚ, sm	Token, Encrypted QSP, Smart contract
θ(·)	One way key generation function
ξkey(·), ξkey(.)	Encryption and Decryption function

A. Transactions between QUS and QC

Two types of major transactions-authentication of QUS and questions handover to QC-take place between QUS and QC. Every user in QUS has a unique signature, which is stored in QC. Each user has to prove his identity with proper credentials to send questions to QC, as shown in Fig. 2. The proposed scheme assumes that all communication between QUS and QC is done by employing asymmetric key encryption. Before sending questions, QUS sends a request to QC to obtain a public key of QC. QUS sends the request by sending data D₁. After getting the request from QUS, QC generates one-time asymmetric keys (OTAKs) for QUS to transfer credentials and questions. QC generates a secret key S_k and a public key ℘_k. Let k be the set of OTAKs:

Figure 2.

Transactions between QUS and QC

(1)$$\begin{array}{r}\overline{\kappa }=\left\{\left(\phi ,\psi \right):\phi \in S_{\kappa }\cap \psi \in {\wp }_{\kappa }|\right.\\ {𝒮}_{\kappa }=\left(\theta \left(\eta +1\right)\times \rho ,{\tau }_c,QT,{𝕊}_{\hslash }\right)\cap {\wp }_{\kappa }\\ ={𝒮}_{\kappa }\otimes \left({𝓖}_x,{𝓖}_y\right)\left.\right\}\end{array}$$

Here, ρ is a large prime number, τ_c is the current timestamp, 𝕊_ħ is a salt hash, and 𝒢 is a set of (x, y) coordinates on the elliptic curve. When QC finishes generating OTAKs, QC sends ℘_k by sending D₂. Upon receiving D₂, QUS encrypts QT and PW employing ξ_℘k(QT,PW). Following this, QUS increases η + 1 by 1 and sends data D₃ to QCM. When QC receives D₃, QC first decrypts data utilizing ζ_Sk(ξ_℘k(QT,PW)) and checks the validity of the credentials provided from QUS. If the credential is valid, then QC returns a success token by sending D₄. Before sending questions, QUS creates a signature using QT and PW. Let ω_sig be the signature:

(2)$${\omega }_{sig}=\text{Θ(}QT,PW\text{)}$$

QUS first encrypts the question using ω_sig and then encrypts using ℘_k. After encryption, QUS sends D₅. As QC receives data from QUS, QC decrypts data by employing ζ_Sk(ξ_℘k(ξ_ωsig(Q)). QC generates a signature employing Eq. (2) and validates the identity of the person by decrypting the question with the sender’s signature.

B. Transactions between QC and master

Here, transactions are divided into two main categories shown in Fig. 3: 1) processing questions within different modules of QC, and 2) sending QSPs from QQ to BSSSQS_master for further processing. After the deadline of question submission, FQ formats and modifies the questions to prepare QSPs. The QSPs are then sent to QNP, where the questions are stored temporarily, and after obtaining proper instructions from QCM, QSPs are sent to QF. QF selects some QSPs based on certain criteria and forwards these selected QSPs to QQ before sending to BSSSQS_master. When the collection is finished, QQ sends QSPs to BSSSQS_master.

Figure 3.

Transactions between QC and BSSSQS_master

C. Transactions between Master and Minion

This segment covers transactions between BSSSQS_master and BSSSQS_minion, as shown in Fig. 4. The primary tasks of BSSSQS_master are summarized as follows: (1) to encrypt QSPs and send these encrypted QSPs to BSSSQS_minion and (2) to select a QSP for the exam and send permission notification to BSSSQS_minion for accessing the selected QSP. BSSSQS_master plays a very significant role in providing security to QSPs. Initially, questions are stored in QNQ. After getting QSPs from QNQ, BMM picks the timestamp τ_c by sending a request to TS. In the subsequent stage, BMM pulls the course list from DB. Next, BMM sends QSPs to QS with τ_c and the course list. Then, QSPs experience two-phase encryption as follows:

Figure 4.

Transactions between BSSSQS_master and BSSSQS_minion.

1) First-phase Encryption

The first phase of encryption is managed by QS. First, QS requests SE for generating a salt hash 𝕊_ħ. After getting 𝕊_ħ from SE, QS stores it for the next phase of encryption. Second, QS sends QSPs to DE with τ_c. DE then encrypts QSPs with τ_c. Let Q_i be the i^th number of QSPs. Therefore, i number of QSPs that experience the first phase of encryption is written by

(3)$${\mathbb{Q}}_i^1={\text{ξ}}_{{\text{τ}}_{\text{c}}}\{Q_i,{\tau }_c\}$$

Finally, QS sends encrypted QSPs to EF with τ_c and 𝕊_ħ.

2) Second-phase Encryption

The second phase of encryption happens in EF. EF generates a default genesis block (i.e., first block) with random text and encrypts it with τ_c. After creating the genesis block, EF encrypts QSPs and converts them into blocks. Each block contains a header and data. The header carries the previous block hash, timestamp, last access time, block creation time, and nonce. Every time EF encrypts a QSP, it sends that encrypted QSP to HG. HG then generates a hash from that encrypted QSP to participate in the next QSP encryption. Therefore, the encrypted QSP that experiences the second phase of encryption can be written as

(4)$${\mathbb{Q}}_i^2=\{\begin{array}{cc}\hfill {\text{ξ}}_{{\text{τ}}_{\text{c}}}\{{\mathbb{Q}}_i^1,{\text{τ}}_c\},& ifi=0\\ {\text{ξ}}_{\{{\text{τ}}_{\text{c}},{\mu }_{{\mathbb{Q}}^{\hslash }},{\mathbb{S}}_{\hslash }\}}\{{\mathbb{Q}}_i^1,{\text{τ}}_c,{\mu }_{{\mathbb{Q}}^{\hslash }},{\mathbb{S}}_{\hslash }\},& ifi>0\end{array}$$

where ${\mu }_{{\mathbb{Q}}^{\hslash }}={\cup }_{\sigma =0}^{i-1}{\mathbb{Q}}_{\sigma }^{\hslash }$. The hash of the i^th QSP is generated by ${\mathbb{Q}}_i^{\hslash }=\text{𝕊ℍ𝔸256}\left({\mathbb{Q}}_i^2\right)$. Then, HG stores the generated hash in DB for QSP selection. Next, EF commands CG to generate a smart contract including the information of ℚ^ħ, τ_c, and 𝕊_ħ. The smart contract contains hashes of QSPs, timestamp, and salt hash. When smart contract generation is completed, CG encrypts the smart contract with a timestamp τ_sm and a random salt hash 𝕊_r. Let ℂ_sm be the encrypted smart contract.

(5)$${ℂ}_{sm}={\text{ξ}}_{\{\text{Θ}({\text{τ}}_{\text{sm}},{\mathbb{S}}_r)\}}\{sm,\text{Θ}({\text{τ}}_{\text{sm}},{\mathbb{S}}_r)\}$$

After the encryption, CG stores the key in DB. At the time of the exam, BSSSQS_master sends the key along with a selected question hash. After getting the encrypted smart contract from CG, EF sends blocks and the smart contract to GB. As GB gets the blocks and contract, it initiates the process of sending these resources to BSSSQS_minion. At first, GB pulls the existing minion list from DB. When GB get all lists, it begins sending blocks and the contract to BSSSQS_minion through the blockchain cloud. When a QSP has to be selected for an exam, GB sends an instruction to QP for initiating the process of selecting a QSP for the exam along with ℂ_sm and notifying the minions about that QSP. Before initiating random engine for picking out a QSP, QP pulls the hash of QSPs from DB. Meanwhile, it also requests EP to send the hashes of the excluded QSPs. When QP gathers all the required information, it starts the process of selecting a QSP as follows. First, QP removes the excluded QSPs from the set of QSPs. Therefore, the set of filtered QSPs Q_F is written by

(6)$$\overline{Q_F}=\{\chi :\chi \in \overline{Q_P}\cap \chi \notin \overline{Q_E}\}$$

where Q_P is the set of all QSPs and Q_E is the set of excluded QSPs. Second, QP takes a collection of 10 large prime numbers which is represented by ρ = {ρ_i∈ ℙ | 0 ≤ i ≤ 9}. Next, it converts the current date and time into a timestamp τ. To select any two prime numbers from ρ, QP takes the last digit $d_{\tau }^l$ and second last digit $d_{\tau }^{sl}$ from t to select prime numbers $p_{d_{\tau }^l}$ and $p_{d_{\tau }^{sl}}$, respectively. The selected QSP to take the exam is represented by

(7)$$Q_s=\{(p_{d_{\tau }^l}-Q_{fn})\times p_{d_{\tau }^{sl}}\}mod{Q}_{fn}$$

where Q_fn is the total number of filtered QSPs and $p_{d_{\tau }^l}\ge Q_{fn}$. As QP selects a QSP, it notifies all BSSSQS_minion about the selection through the blockchain cloud.

D. Transactions in BSSSQS_minion

This section covers the transactions between different modules of BSSSQS_minion, as shown in Fig. 5. Note that U in Fig. 5 represents a user in the system. The transactions are categorized into the following three types: (1) storing and maintaining QSP blocks in blockchain, (2) updating the smart contract, and (3) alerting authority about the permission to access QSPs. After getting blocks and the smart contract, BMNM sends blocks to BC and smart contract to SCM for the selected exam. When BMNM gets a QSP selection notification from BSSSQS_master, BMNM passes this notification to UP and UP alerts users about the access. When a user tries to enter UP, he has to experience a validation process. UAAM sends a request to DB to send information regarding the requested signature. If the user is valid, DB returns user information, otherwise, it reruns empty data. When UAAM gets validation from DB, it stores a token in SM for maintaining the user session. Every minion manages its users by itself. After that, UAAM notifies UP about the response. As users get a notification about the QSP and key for decrypting ℂ_sm, they request for QSP through UP. UP requests SCM to start the decryption process. Before going further, SCM sends a command to MB to check whether QSP is unlocked for access. MB affirms authorization with BSSSQS_master. With proper authorization, SCM transfers the request to BC. BC performs a final authorization check with BSSSQS_master through MB. If BC gets an unauthorized request with a QSP, it changes access time and nonce and mines the chain again. It changes the signature of all the QSPs, and no one can get its key hash. Whenever BC gets an affirmative result, it sends the QSP to SCM for decrypting. First, SM decrypts ℂ_sm to the selected QSP. Let D_sm be the decrypted smart contract, D_sm = ζ_{{Θ(τsm,𝕊r)}}{ℂ_sm,Θ(τ_sm,𝕊_r)}. After getting D_sm, QSP decryption begins. Let Q be a selected encrypted QSP. By utilizing μ_ℚħ in Eq. (4), the first phase of decryption is written by

Figure 5.

Transactions in BSSSQS_minion

(8)$$D_{Q1}={\zeta }_{\{{\tau }_{c,}{\mu }_{{\mathbb{Q}}^{\hslash }},{\mathbb{S}}_{\hslash }\}}\{\mathbb{Q},{\tau }_c,{\mu }_{{\mathbb{Q}}^{\hslash }},{\mathbb{S}}_{\hslash }\}$$

Finally, D_Q1 goes through the second phase of decryption which is written by

(9)$$D_{Q2}={\zeta }_{\left\{{\text{τ}}_{\text{c}}\right\}}\left\{D_{Q1}{\text{τ}}_{\text{c}}\right\}.$$

where D_Q2 is the QSP which experiences the second phase of decryption. After decryption, SC stores the QSP to DB and sends a notification to UP about the outcome. Finally, users can retrieve QSP from DB to take an exam.

In this section, we propose different propositions related to security against different attacks with proof.

Proposition 1. The secret key of QC is well protected from the adversary.

Proof. QC’s secret key is generated using Eq. (1). Suppose, adversary A wants to steal the secret key of QC. The only way to get the secret key of QC is to guess the private key, to the best of our knowledge, as QC never shares its private key with anyone. However, in asymmetric encryption, suppose the secret key is 256 bits long. To guess the correct secret key, A needs to guess the sequence of 256. For 256 bits, there are 2²⁵⁶ possible sequences, and among them, only one can be the QC’s secret key. The probability of guessing the secret key is 1/2²⁵⁶ = 2⁻²⁵⁶ which is practically not feasible. Moreover, if A wants to guess the properties of the secret key individually, A has to face the probability of randomness in each property which is also practically not feasible. Furthermore, OTAK is temporary. When questions are transferred successfully, OTAK, which is generated for particular QUS, is removed from QC. Therefore, the secret key may become obsolete while A is still trying to guess the secret key. Thus, QC’s secret key is well protected from the adversary.

Proposition 2. Communication between QUS and QC is secure even in the presence of an eavesdropper.

Proof. The motive behind the communication between QUS and QC is to transfer questions. To send questions, QUS requires QC’s public key to create a digital signature using Eq. (2) and encrypt questions employing ξ_℘k(Q). However, when QUS requests for the OTAK, QC generates OTAK utilizing Eq. (1). When QUS gets ℘_k, first, QUS validates its identity by transmitting QT and PW, which is encrypted using ℘_k, to QC. Second, it generates a digital signature by applying Eq. (2). Finally, QUS encrypts questions using ℘_k and sends the questions back to QC signed with its signature. Suppose, there exists an eavesdropper named B between QC and QUS. B wants to steal the credentials of QUS along with questions and also wants to send false data to QC. B catches data between QUS and QC and wants to extract D₂ and D₅ data, as shown in Fig. 2. To extract data, B requires QC’s private key, which is not available to anyone except QC. Moreover, there is no feasible solution to extract the private key from public key by reverse engineering or guessing, as discussed in Proposition 1. However, B wants to send false data encrypted by ℘_k to QC. When QUS send questions to QC, QUS signs the question with its signature. From the signature, QC verifies the actual source of the data. As B needs the signature of QUS, B cannot send false data until it obtains QUS’s signature and not only is QUS’s signature not only publicly available but also QUS never shares its signature with other people apart from QC in an encrypted form. As a result, B cannot achieve any of the aforementioned objectives.

Proposition 3. QSP selection in BSSSQS_master is totally random and is free from compromised QSPs.

Proof. Before the exam, BSSSQS_master selects a QSP and sends that QSP reference to BSSSQS_minion. This process is completely random. Before selecting a QSP, BSSSQS_master selects a set of 10 prime numbers. Each prime number is selected following uniform distribution. Let, ℙ be the set of prime numbers and ρ be the set of already selected prime numbers. Therefore, the probability of selecting prime numbers is P(ℙ − ρ). Finally, QSP is selected by employing Eq. (7) which gives a random QSP number. BSSSQS_master is a well-protected scheme. By any chance, if any QSP becomes compromised, BSSSQS_minion notifies BSSSQS_master about that question. BSSSQS_master excludes that compromised QSP from the selection process by employing Eq. (6) to remove compromised QSPs.

Proposition 4. QSPs and smart contract are secure from physical attacks by both insiders and outsiders.

Proof. Physical attacks involves exploiting the weakest point by the attacker to breach the security system. However, attackers may not always come from outside. Sometimes, a person from the inside may also harm the system. As we discussed in the Introduction, sometimes a teacher or authority may leak the question, so it is very important to provide protection from attacks is caused by both outsiders and insiders. BSSSQS imposes a timelock on the QSPs and the smart contract. If anyone tries to access both of them before the allowed time, the system notifies not only BSSSQS_master but also BSSSQS_minion. Suppose, an attacker X from inside wants to steal QSPs. X disables the connection of BSSSQS_minion and tries to copy QSPs from a disk. QSPs access permission is locked, which can be unlocked by the permission from BSSSQS_master. However, X somehow bypasses the access protection and starts to copy. An internal monitoring system monitors this activity and changes the QSP auditing time, which changes the hash of QSPs and breaks the chain of the block. When BSSSQS_minion comes online, BSSSQS_minion notifies BSSSQS_master, and BSSSQS_master excludes the BSSSQS_minion from taking the exam. However, after copying the QSPs, X needs a private key to unlock both QSPs and the smart contract, which are encrypted by employing Eq. (4) and Eq. (5), respectively. In Proposition 1, we discussed that it is not feasible to guess a key. Therefore, copying the QSPs will not help X. This outcome is the same for outsiders too. In this way, QSP and smart contracts are secure from physical attacks.

In this section, we discuss the experimental results and compare the proposed BSSSQS with existing schemes based on different features to demonstrate the feasibility of BSSSQS.

A. Experimental Results

Three computers were considered for the experiment. Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz was considered as QUS with 16 GB. Microsoft Windows 10 Professional 64-bit was used as an operating system (OS) in QUS. Intel(R) Xeon(R) Processor E5-2697A V4 @ 2.60 GHz was considered as QC and BSSSQS_master with 32 GB. CentOS 7.5 was utilized as an OS in QC and BSSSQS_master. Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz was considered as BSSSQS_minion with 32 GB. Ubuntu 18.04.1 LTS was utilized as an OS in BSSSQS_minion. RSA was considered for asymmetric encryption, and Twofish was considered for symmetric encryption. The middleware in QUS was built using Node.js, the middleware in QC was built using PHP, and the middleware in BSSSQS_master and in BSSSQS_minion was built using Python. The blockchain network was built and maintained using Python. As the proposed BSSSQS is a private network and blocks were created in BSSSQS_master, no consensus mechanism was considered during the experiment. Fig. 6 represents the result of the experiments performed in BSSSQS. In Fig. 6(a), time to transfer questions (TTQ) from QUS to QC is demonstrated for different question sizes. Requesting public key and validation of user identity is also included in TTQ. With the increasing size of questions, TTQ also increases. This is because more time is required for encrypting and transferring larger questions over the network. Fig. 6(b) illustrates the processing time for performing security mechanisms in BSSSQS_master and BSSSQS_minion. The processing time increased with increasing QSP size for phase-1 and phase-2 encryption in BSSSQS_master and phase-1 and phase- 2 decryption in BSSSQS_minion. The computation power in BSSSQS_master is much higher than that of BSSSQS_minion . Thus, the processing time in BSSSQS_master is lesser than that in BSSSQS_minion. Eq. (3) and Eq. (4) were utilized for calculating the processing time while performing phase-1 and phase-2 encryption in BSSSQS_master, respectively. Eq. (8) and Eq. (9) were used for calculating the processing time while performing phase-1 and phase-2 decryption in BSSSQS_minion, respectively. Phase-1 encryption requires less time than phase-2. This is because the key is generated from the previous block’s hash, and the size of the key in phase-2 increases with the increase of block. Phase-1 decryption takes more time than phase-2 decryption. To decrypt in phase-2, the hash of the previous block is required and a combination of the previous block’s hash increases the key size. Fig. 6(c) depicts the block creation for different QSP sizes. With the increase in the size of QSP, block creation time also increases. The block contains QSP, timestamp, nonce, and the previous block’s hash. While creating blocks, data were encrypted. After preparing the aforementioned attributes, the block is created and a hash is generated that works as the identity of the block. The higher the QSP size, the more time is required for encrypting data and generating the hash. Thus, the block time increases. Fig. 6(d) demonstrates the change in the block size for different QSP sizes. With increasing size of QSP, block size also increases. Fig. 6(e) portrays the change in time for selecting the QSP for the different number of QSPs. Eq. (6) and Eq. (7) were used during calculating time for selecting the QSP. When the number of QSPs is increased, QSP selection time also increases because the more QSPs in the list, the more time is required to filter compromised QSPs. Overall, the increase in QSP selection time is very small.

Figure 6.

Experimental result performed in BSSSQS: (a) time to transfer questions (TTQ) from QUS to QC, (b) processing time for performing security actions for different size of QSPs, (c) time for creating block in blockchain, (d) size of the block after adding QSPs, and (e) time to select QSP before the exam for different number of QSPs

B. Performance Comparison

A comparative study between BSSSQS and existing models ([48]-[54]) was performed, as shown in Table 2, where (√) means supported and (×) means not supported, by considering the following features.

Table 2 .

Performance comparison.

Features	Schemes
	Yang [50]	Chang [48]	Lu [51]	Zhai [52]	Henke [53]	Kaya [49]	Younis [54]	BSSSQS
Secure login	√	√	√	√	√	√	√	√
QSP generation	×	√	√	√	×	√	√	√
QSP encryption	×	×	×	×	×	×	×	√
QSP selection	×	×	×	×	√	√	√	√
Timestamp lock	×	×	×	×	×	×	×	√

• • Secure login: This feature covers the security in the login process like password encryption, random password, etc. BSSSQS along with all of the existing models (([48]-[54]) support secure login.

• • QSP generation: This feature generates a QSP randomly from a list of questions. BSSSQS randomly generates QSPs from the provided questions and among the existing systems. Chang [48], Lu [51], Zhai [52], Kaya [49], and Younis [54] supported this.

• • QSP encryption: This feature encrypts the QSP to prevent unauthorized access. Only BSSSQS performs encryption in QSPs.

• • QSP selection: This feature supports the random selection of a QSP. BSSSQS randomly selects a QSP, and among the existing systems, Henke [53], Kaya [49], and Younis [54] support this feature.

• • Timestamp lock: This feature helps impose a restriction of time on QSPs so that no one can access QSPs before the allowed time. Only BSSSQS imposes a timestamp lock on the QSPs.

In this study, we proposed a secured QS scheme exploiting the security mechanism of blockchain. In this scheme, QSP experiences two-phase encryption to prevent unethical access before the exam. Moreover, a restriction of time is issued in the proposed scheme so that every minion has to wait for system permission to initiate the decryption process of QSP. Furthermore, QSP is selected by master employing the proposed randomize algorithm. A combination of these features can provide a secured QS system. We analyzed BSSSQS’s security by proposing different propositions with proofs. We compared the performance of BSSSQS with other existing education management schemes. Based on the theoretical comparison, it can be demonstrated that BSSSQS is more secure than other models. We implemented BSSSQS and performed experiments on the implementation to show the effectiveness of BSSSQS. Therefore, we can conclude that BSSSQS can be a promising approach for providing proper security to mitigate the QPL problem in the future smart education system.