The EduASAC system architecture is shown in Fig. 1, which mainly includes four major entities: government, educational institutions, storage servers, and blockchain.

1) Educational Institution: Educational institutions refer to schools, training institutions, educational enterprises, and other organizational units involved in student education. As the largest subject in the EduASAC system, each educational institution has a lifetime-bound account on the blockchain, where keys and identity information are stored. The identity information of the new educational institution is verified by the member nodes of the whole network and then joins the network after voting. Educational institutions can carry out the process of uploading, retrieving, and downloading education archives; set access rights to education archives to define the scope of data sharing; and request access tokens for target education archives.

2) Storage Server: As another main body in the EduASAC system, the storage server can provide educational institutions with services such as cryptographic storage of education archives, homomorphic cryptographic retrieval, and source data download. It can verify the identity legality of the data requestor and the authenticity of the access token on the chain and run the homomorphic ciphertext retrieval mechanism in the database after verification is passed.

3) Government: The only authoritative entity in the field of education, with the force of law and administrative capacity. The government can be divided into three major departments: management, secrecy, and supervision. Different departments have different identities, different participation links, and different roles in the system. The following describes separately:

Management Department: responsible for the off-chain verification of the identity information of the nodes requesting to join; able to assign the static access permission level of the system based on the identity information; publish the verified identity information and level on the chain, and initiate Vote Contract to count the opinions of the whole network on the new nodes joining the network; record all registration behaviors and voting results on the chain.

4) Blockchain: blockchain is the underlying technical architecture of the system and is responsible for promoting the network-wide voting process, verifying entity identity information, sharing system security parameters, enforcing data access control, and recording system behavior and data. The on-chain nodes are responsible for constructing new transactions from the uploaded, shared data, packaging them into blocks after verification, and recording all behaviors and data of the system as evidence of future review and accountability by the Supervision Department.

In addition to the system architecture briefly described above, to simplify the description of the scheme, this paper divides the system participants into two identity entities, i.e., Data Owners (DO) and Data Users (DU):

DO: It has the authority to manage, control, and share education records, is the owner of interests related to the data, and can set data access permission to control the scope of sharing.

The threat model of the EduASAC system is divided into three levels:

Data threat level: The data threat level defines that the attacker performs some illegal operations on the data without the data owner’s knowledge or against the data owner’s will, thereby endangering the privacy of the user’s identity and the value of the data.

This paper aims to achieve the following threat model goals:

The public key encryption algorithm is used to encrypt the data, and the private key is stored confidentially to ensure the security of the encrypted data; some sensitive data are stored on the chain, relying on the anti-tampering feature of the blockchain to ensure the integrity of the data.

As a core module of the system architecture, access control is based on improving the ACE authorization framework, DAC, and MAC model, with enhanced security and availability as research objectives.

Internet Engineering Task Force (IETF) ACE [21] proposes a generic framework for authentication and authorization in restricted environments-an ACE based on OAuth 2.0 [26]. DO do not have the ability to control access by themselves and need to issue tokens through third-party authorization servers to control access to sensitive, protected resources. To securely distribute Tokens with access control capabilities must establish a secure channel between users and authorization servers to encrypt data and verify the identity or use technologies such as certificates and secret sharing. At the same time, the third-party authorization server that performs access control according to the user’s wishes must be honest and trustworthy to ensure the authority and authenticity of the Token. These problems make the application of the ACE framework subject to multiple environmental constraints, with low security and availability. The research work in this paper uses blockchain instead of a third-party authorization server in the ACE framework, and smart contracts are responsible for generating access Tokens and storing them securely on the chain for other users to query and verify.

DAC means that the data owner can autonomously grant or withdraw access permissions for the object requesting access to the data. The research work in this paper uses an ACL to add, change, and delete user access permissions dynamically. It combines with MAC to improve access control management’s flexibility, reduce access control mechanisms’ operating costs, and make the system scheme more robust and available.

MAC is a mandatory security attribute setting rules for all subjects, where the system decides whether the user can access according to the user’s fixed security attributes. The research work in this paper adopts static permission levels as the fixed security attributes. They are collectively referred to as Static Access Control (SAC) below for ease of description. It can make up for the decentralized permission control ability of ACL. Because the system forcibly sets the static authority level, it has unchangeable and strong control characteristics and improves user permissions’ security.

In this subsection, we define the designed system security parameters. The parameters include four Identity Documents (ID) of Data Owner (IDDO), Data User (IDDU), Data (IDdata), and Access Token (IDtoken), two access control policies (P) of SAC and ACL, three mappings (M) of Verification Parameter Mapping (MV), Retrieval Parameter Mapping (MR), and Encryption Parameter Mapping (ME), four smart contracts of Vote Contract, Mapping Contract, Access Control Contract, and Control List Contract, three attributes of User, Data, and T with the access token (Token). The used symbols are described in Table 1. The above system parameters are defined as follows: P={SAC, ACL} M={MV,MR,ME} MV={IDDO,IDdata,VP} MR={IDDO,IDdata,C(RK)} ME={IDDO,IDdata,C(EP)} User={IDDO(IDDU),PK,SK, Info, S} Data={IDdata,VP,RP,EP,K,D} T={IDtoken,C(RK),C(EP)}

As shown in Fig. 2, the entire workflow of the system is divided into four parts. This section will detail the specific steps of each part, and the symbols are shown in Table 1. 1)

Register

When an educational institution joins the network, it sends a registration application to the government. As the guide node, the Government Management Department verifies the identity information of the node off-chain and publishes it on the chain, and then initiates a Vote Contract to vote for the joining request of the new node by the nodes of the whole network.

Step 1 When an educational institution applies to enter the EduASAC system, it will send Info to the government off-chain, including the institution’s name, type, number, and relevant identity certificates. The Government Management Department is responsible for verifying the authenticity of the Info.

Step 2 After the Government Management Department approves, the static node access level SInfo is allocated according to Info. Pack {Info,S} into Message, forming a transaction and publishing it on the chain.

(1)Build(Info,SInfo)→Message

Step 3 The Government Management Department calls Vote Contract to initiate an on-chain vote. The nodes of the entire network participate in the voting within the voting period, and the contract automatically counts the number of votes. If the consent vote exceeds 90% of the total votes, the contract returns the Yes result and allows the new node to join; otherwise, it returns the Refuse result and rejects the new node. (2)Vote Contract(Message)→Yes→join (3)Vote Contract(Message)→No→refuse

Step 4 Vote Contract will record the results on the chain after the voting is completed, providing valid evidence for the follow-up work such as review and accountability. Details are shown in Table 2.

Step 5 When a new educational institution joins the EduASAC system, it will act as a blockchain member node. Certificate Authority (CA) creates a certificate for it, generates a public key (PK) and secret key (SK), and deposits them in the wallet. PK is published to the public as a blockchain address, a unique identifier on the chain of educational institutions to participate in or link to the blockchain network. SK is secretly stored for transaction signatures or decryption of secret data. 2)

Data Management

DO first processes the data with various algorithmic mechanisms for the education archives that must be uploaded to the storage server, generating parameters that participate in the sharing and access control process. Then DO invokes the Mapping Contract to establish three parameter mappings and store them securely on the chain for easy calling by other system entities when performing arithmetic operations on the data.

Step 1 DO generate parameters or keys EP, RP and VP off-chain applying them to homomorphic encryption, ciphertext retrieval, and access control processes, respectively. The VP settings are shown in Table 3. (4)Build(IDDO)→{VP,RP,EP}

Step 2 DO extract n(n≥1) keywords K1, K2, K3,⋯,Kn from the education archive and set static access permission level Sdata for the education archive. (5)Build(IDdata)→Sdata

Step 3 DO homomorphically encrypts the education archive with EP and sends it to the storage server; homomorphically encrypts the keywords with the same EP; encrypts the EP with PK of the Government Secrecy Department to get C(EP); for the ciphertext keyword list and RP, encrypt them with PK of the storage server to form C(RK). This step is the data processing process, the algorithmic process runs off-chain, and the computing process can be changed according to the system scheme design. (6)Encrypt(D)EP→C(D) (7)Encrypt(K1, K2, K3⋯Kn)EP→{C(K1),C(K2),C(K3)⋯C(Kn)} (8)Encrypt(EP)PK→C(EP) (9)Encrypt(C(K1),C(K2),C(K3)⋯C(Kn),RP)PK→C(RK)

Step 4 DO invokes Mapping Contract to establish ME, MR, and MV and stores the three mapping on the chain. Different mappings will be used in different system entities and steps, effectively reducing the correlation between algorithm parameters and keys and facilitating system management and sharing. (10)Build(IDDO,IDdata,C(EP))→ME (11)Build(IDDO,IDdata,C(RK))→MR (12)Build(IDDO,IDdata,VP,Sdata)→MV 3)

Access Control

The access control process of the EduASAC contains SAC, ACL, or other access control mechanisms to realize DO fine-grained access control education archives.

Step 1 DO calls Control List Contract as needed to set data access permissions on the chain. The process will be matched to the VP values, as shown in Table 2. (13)Build(IDDO,IDdata)→P={SAC, ACL}

SAC: the Sdata of the data has been set when DO creates the MV of the education archive. The SInfo of educational institutions has been configured by government management according to the Info of educational institutions and voted by the member nodes of the whole network.

Step 2 DU calls the Access Control Contract to request access to the target data. The contract validates DU access permissions according to DO’s access control management of the data. When the access permissions are verified, the contract generates Tokens and forms blockchain transactions stored on the chain. (14)Access Control Contract(IDDU,IDdata)→Token

Step 3 Access Control Contract will record the access control process and results for review and accountability by the Government Supervision Department. The access control information records are shown in Table 6. 4)

Data Sharing

Step 1 DU sends IDDU and IDdata to the storage server on the chain, requesting C(D).

Step 2 The storage server queries the Token and verifies the validity according to the correspondence of IDDU, IDdata, and IDtoken stored on the chain. After passing, SK is used to decrypt some parameters of the Token to obtain RP, C(K); the homomorphic ciphertext retrieval mechanism is run to get C(D) returned to DU. (15)Decrypt(C(RK))SK→{C(K1),C(K2),C(K3)⋯C(Kn),RP} (16)Retrieval(C(K1),C(K2),C(K3)⋯C(Kn))RP→C(D)→DU

Step 3 DU sends C(D) through the off-chain secure channel to the Government Secrecy Department to request a re-encryption process to obtain D. This step aims to reduce the range of key sharing and improve key security.

Step 4 According to the correspondence of IDDU, IDdata and IDtoken stored on the chain, the Government Secrecy Department queries the Token and verifies the validity; after passing, decrypts some parameters of the Token to obtain EP using SK; runs the re-encryption process and returns the DU decryptable education archive. The re-encryption process is that the Government Secrecy Department Decrypts C(D) with EP, then queries PK of DU on the chain, and re-encrypts the education archive back to DU. (17)Decrypt(C(EP))SK→EP (18)Decrypt(C(D))EP→D

Step 5 DU uses SK to decrypt the education archives of the cryptographic state.

The ciphertext retrieval scheme [27] based on a homomorphic encryption algorithm was first proposed by BONEH [28], and it is based on Difficulties in cryptography. The strategy is to obtain retrieval results by comparing homomorphic ciphertext and ciphertext keywords with high data security and retrieval efficiency. The EduASAC system proposed in this paper can be used with most homomorphic ciphertext retrieval schemes running on storage servers to achieve decentralized fine-grained access control and efficient data sharing.

Homomorphic encryption schemes generally consist of four Probabilistic Polynomial Time (PPT) algorithms [29]. The specific content is as follows: 1)

Key generation algorithm (KeyGen). Input security parameters and public parameters that meet other actual needs and can output the encryption key (public key), the decryption key (private key), and the public key used for homomorphic ciphertext calculation.

In the workflow shown in Fig. 2, Mark 2.1 corresponds to KeyGen (). DO generates keys and security parameters of the homomorphic encryption algorithm. Mark 2.2 is DO extracts keywords from archives. Mark 2.3 corresponds to Encrypt (), DO encrypts education archives and keywords and uploads them to the storage server and blockchain. Mark 4.4 corresponds to Decrypt (), the government department decrypts education archives, performs re-encryption operations, and then shares them with DU. Mark 4.2 corresponds to the homomorphic ciphertext retrieval algorithm Retrieval (), which is run independently by the storage server. The above steps are all run off-chain. It can effectively reduce the amount of computation on the chain, improve the system’s scalability, enable the system framework to be used in conjunction with most homomorphic ciphertext retrieval schemes, and meet the different needs of different retrieval schemes for access control.

The EduASAC system provides the following services for the homomorphic ciphertext retrieval mechanism: 1)

For the key and security parameter EP of the homomorphic encryption algorithm, it is packaged to form ME and stored on the chain.

The above content can be set according to user needs and the homomorphic ciphertext retrieval scheme. For example, the generation algorithm of the key and security parameter EP is set according to the homomorphic encryption scheme; when the homomorphic ciphertext retrieval process does not require additional security parameters, there is no RP setting; DO implement different levels of access control for different education archives and users.

The Government Management Department invokes the Contract and can initiate the voting of the entire network nodes on the educational institutions applying to join the network. After the voting, the Contract will automatically count the votes, return the information of allowing or rejecting the joining request, and record the voting results in a table on the chain, see Table 2 in the previous section. The specific content of the Contract is as follows:

VoteInstitution(): As shown in Algorithm 1, member nodes vote before the voting deadline. Info is the identity information of the voting node. Nodes vote for the Info included in the AccessmemberMap mapping and against the Info in the RefusememberMap mapping. Both mapping records will be uploaded to the chain. The two-mapping records deadline is the voting period, a fixed value stipulated and released by the Government Management Department on the chain.

typedefine <Struct> Info{

  ID: String.

  Publickey: String.

  Verification: String.

  Level(SInfo): String.}

VoteCounting(): As shown in Algorithm 2, after the voting deadline, the votes are counted. When the approval votes account for more than 90% of the total votes, new nodes are allowed to join. Otherwise, the joining request is rejected. The percentage of votes allowed to join can be changed according to actual needs.

institutionMap(): As shown in Algorithm 3, this function describes the process of establishing a mapping between ID and Info, which is executed by newly joined member nodes to initialize their official information and provide parameter records for the subsequent process of verifying user identity.

isExitInstitution(): This function checks whether the educational institution applying to join already exists in the network to prevent the internal nodes from sending many requests to affect the system’s proper operation.

addVoteCase()/queryVoteCase(): Upload or query events that require member nodes to vote, including the id, name, content, time limit, and the number of votes in favor and against. In the initial state, the number of votes in favor and against is 0; after the voting, this value is the final result provided to VoteCounting() for calculation.

This Contract is invoked by DO, who uploads education archives and hopes to share them with other users, to establish three parameter mapping: ME, MR, and MV. It can associate DO identity information, education archives information, and parameters required for system work and serve the homomorphic ciphertext retrieval, access control, and re-encryption process. DO initiates the Contract, and its blockchain address needs to match the input IDDO so that the Contract can normally execute the process of establishing, updating, deleting, and querying parameter mapping. The specific content of the Contract is as follows.

initVerifyMap()/initRetrievalMap()/initEncryptMap(): Establish validation parameter mapping, retrieval parameter mapping and encryption parameter mapping process, as shown in Algorithm 4. The same input parameters of the three functions are the IDs of DO and data, and the different input parameters are VP and Sdata, C(RK), and C(EP).

typedefine <Struct> VerifyPara{

  IDDO: String.

  IDdata: String.

  Validation parameter: String.

  Level(Sdata): String.}

typedefine <Struct> EncryptPara{

  IDDO: String.

  IDdata: String.

  Encryption parameter: String.}

typedefine <Struct> RetrievalPara{

  IDDO: String.

  IDdata: String.

  Retrieval parameter: String.}

updateVerifyMap()/updateRetrievalMap()/updateEncryptMap(): It is the same as the input of establishing the mapping function, and the old mapping is overwritten with IDdata, as shown in Algorithm 5.

deleteVerifyMap()/deleteRetrievalMap()/deleteEncryptMap(): Need to input the IDs of DO and data to delete the corresponding parameter mapping, as shown in Algorithm 6.

queryVerifyMap()/queryRetrievalMap()/queryEncryptMap(): Query validation parameter mapping, retrieval parameter mapping and encryption parameter mapping procedures, as shown in Algorithm 7. Need to input the IDs of DO and data to query the parameter mapping and return the corresponding parameter or error reminder information.

The role of this Contract is for the DO to perform access control management on shared education archives and call the Contract to manage and maintain two types of lists on the chain, namely the DAAL and the DDAL. As the contract initiator, DO’s blockchain address needs to match the input IDDO, and then the Contract can be called to add, delete, and modify the list.

addAllowList()/updateAllowList()/deleteAllowList ()/queryAllowList (): This function is to add, delete, modify, and query table items in the DAAL.

addDenyList()/updateDenyList()/deleteDenyList()/queryDenyList(): This function is to add, delete, modify, and query table items in the DDAL.

This Contract is the core of the system access control process and is used to verify the access permissions of the person who initiated the Contract. The Contract is designed according to the EduASAC system scheme, and the verification parameter mapping corresponding to the target data is queried on the chain. According to VP settings, execute the related access control process to verify DU access permissions. After the verification is passed, a Token is generated for the legal DU and stored on the chain, which can be used for subsequent operation of the homomorphic ciphertext retrieval mechanism and re-encryption process.

checkAccess(): Check DU access permissions, as shown in Algorithm 8. The input is the IDs of DU, data, and DO. A Token is generated if the verification is successful; otherwise, empty data returns to indicate that the verification failed. The access control mechanism adopted by the system will be based on the VP value set by DO. See Table 3 in the previous section.

If VP is 0, no verification permission is required to access data, and the contract directly generates a Token.

According to the threat model mentioned in Section 3.2, this section theoretically analyzes the specific solutions proposed by the EduASAC system for data threat, entity identity threat, and system behavior threat. 1)

Data security on the chain

The EduASAC system uses the blockchain network to store and share the data used or generated during the system’s work. It deploys the smart contract that regulates the system’s behavior on the chain to record the data operation process and ensure the data’s integrity, correctness, and validity. Table 7 below is the security data stored on the chain.

One data item is not listed in the above list, i.e., all system workflow records stored on the chain. These records will serve as evidence of dishonest behavior by system entities and reduce the impact of malicious tampering of execution results or changes to the execution process by system entities. It can also provide extremely reliable data records for authorities’ subsequent review and accountability process. 2)

Parameter security

The generation, storage, and sharing of security parameters in the EduASAC system are all done by DO alone without third-party participation. Each workflow of the system is modularized, and different system working mechanisms require different security parameters, which can meet the security requirements of different mechanisms. The security parameters required by a system entity to run a certain mechanism have been encrypted by the asymmetric key of the system entity and stored on the chain in a ciphertext state. a)

The access control mechanism needs VP when verifying access permissions. Because it does not involve the security of the data itself, the access control policy setting of the data by DO, therefore, VP does not need to be stored in a ciphertext state and can be viewed by any system entity.

This section explains the research characteristics, application advantages, and realization value of the EduASAC system by comparing the performance of related research schemes and conducting simulation tests. 1)

Test environment

The performance test environment is shown in Table 8. 2)

Performance analysis

Table 9 below will use the designed EduASAC system as the base point to compare the data characteristics of the shared system under different storage modes.

The system solution in this paper uses a combination of storage server and blockchain to store different data based on two different storage models, centralized and decentralized ledger, to jointly complete the work of sharing the data. As shown in the above table, the blockchain is a distributed structure, an open platform, without third-party participation and user access control. At the same time, because the authenticity of pre-chain data cannot be verified, there is a security threat of legitimate users uploading illegal data. There are third-party government departments with the force of law and administrative capacity in the EduASAC system, which can guarantee data security, verify data authenticity, and protect user identity privacy. Therefore, the advantages of system data characteristics are significant, and the social application value is greater. Table 10 below compares the research schemes of other blockchain education systems, highlighting the uniqueness of the scheme in this paper.

By comparing the system’s characteristics, it can be concluded that there is originality in the research of EduASAC system. It can be combined with most homomorphic ciphertext retrieval schemes. It adopts on-chain authorization and off-chain storage, integrates multiple access control modes, and realizes sharing and access control of educational archives based on smart contracts. Table 11 compares other system research schemes that run access control policies on the blockchain.

As can be seen from the Table 11, compared with the centralized trusted institutions used in the literature [18] to manage access permissions, this paper uses a distributed network of blockchain without trust relationship to manage access permissions, which solves the problems of single point failure and third-party service trust; compared with the literature [19] based on static access permissions verification, this paper adopts a combination of static and dynamic access permissions verification mode, which has higher system flexibility and usability; compared with the literature [22,23], which use encryption or signature technology to control access to sensitive data, the security encryption technology used in this paper does not play a role in access control, but ensures the security of data sharing on the chain and reduce security threats from members of the system; compared with the public platform of the Ethernet blockchain used in literature [24], the newly registered system entities in this paper need to be joined after a whole network voting vote; literature [25] is similar to the research scheme of this paper, but the access control mechanism and specific application scenarios adopted by both are different, and this paper also combines homomorphic ciphertext retrieval mechanism and improves the access authorization framework. By comparing various research works, the safety, efficiency, and functional advantages of the scheme in this paper are outstanding, and it has high research significance and application value. 3)

Test results a)

Test contract efficiency

On the Hyperledger Fabric, test the running time of installing and instantiating four EduASAC system smart contracts, and test the impact of the average memory of the contract Docker container and the number of APIs in the contract on the contract initialization efficiency, as shown in Fig. 3.

Smart contract code written in the Go language generally cannot run directly on the blockchain but needs to be run in a specific sandbox environment Docker container. The installation process is that the smart contract is uploaded to the chain, and the running time is short. The instantiation process needs to call the Docker container and initialize the smart contract, which takes a long time. As can be seen from the figure above, the on-chain efficiency of different smart contracts is related to the amount of memory in the Docker container, the number of APIs, and the complexity of the system behavior controlled by the contract. Tested the average latency and Central Processing Unit (CPU) of the three contracts when writing and querying ledger data, as shown in Fig. 4; tested the average latency and throughput of AccessControlContract under different transaction numbers, as shown in Fig. 5.

The experimental results in the above figure show that the EduASAC system can maintain high throughput in a large-scale transaction environment with high efficiency and low latency. It enables all network parties to reach a low-cost consensus to ensure data consistency. b)

Test contract API

To illustrate the system performance of EduASAC, four contracts of the EduASAC system are called, and the running time of each contract API was recorded in detail. The specific test results are shown in Figs. 6–9.

Note: checkAccess() in the Access Control Contract is when VP is set to 0, the API running time without access control.

API is the behavior code for smart contracts to perform specific operations on data on the chain, including adding, deleting, updating, and querying data. As can be seen from the figure above, the operating efficiency of codes of the same behavior is roughly the same, and the subtle difference is the amount of data stored on the chain and the amount of data of the operation object. The scheme in this paper stores and shares the parameters relating to the homomorphic ciphertext retrieval scheme and access control strategy on the chain. Asymmetric algorithms encrypt all of them. Mechanisms with a large amount of calculation are all run off-chain, and education archives with a large amount of data are stored in the storage server. The data operated by smart contracts on the chain has high security, a small amount of data, and simple operation, improving the EduASAC system’s operating efficiency to a certain extent. c)

Test access verification

When DO sets different VP parameters for shared data, different access control mechanisms will operate in the Access Control Contract. In the experimental system of EduASAC, the process of DU calling checkAccess() in the Access Control Contract to verify the access permission has been simulated. The specific running time of 9 verification access permission workflows has been tested. Table 12 below shows the previous conditions for operating the nine verification access permissions processes.

In the simulation test, if DU’s access request to the data is allowed, the test content will include the generation of the Token and the storage process on the chain; otherwise, the contract will end directly after the verification permissions fail. Fig. 10 below shows the running time results of checkAccess() in the Access Control Contract under different conditions.

It can be seen from the figure that compared with the running time of checkAccess() without access control when VP is 0, the efficiency of the various access control processes designed in this paper is higher, and the running time of Token generation and on-chain storage is shorter. It shows that the EduASAC system using smart contracts for on-chain access control is well-designed, with low operating costs, high efficiency, and high application value.