An Autonomous Log Storage Management Protocol with Blockchain Mechanism and Access Control for the Internet of Things

As the Internet of Things (IoT) has become prevalent, a massive number of logs produced by IoT devices are transmitted and processed every day. The logs should contain important contents and private information. Moreover, these logs may be used as evidences for forensic investigations when cyber security incidents occur. However, evidence legality and internal security issues in existing works were not properly addressed. This paper proposes an autonomous log storage management protocol with blockchain mechanism and access control for the IoT. Autonomous model allows sensors to encrypt their logs before sending it to gateway and server, so that the logs are not revealed to the public during communication process. Along with blockchain, we introduce the concept “signature chain”. The integration of blockchain and signature chain provides efficient management functions with valuable security properties for the logs, including robust identity verification, data integrity, non-repudiation, data tamper resistance, and the legality. Our work also employs attribute-based encryption to achieve fine-grained access control and data confidentiality. The results of security analysis using AVSIPA toolset, GNY logic and semantic proof indicate that the proposed protocol meets various security requirements. Providing good performance with elliptic curve small key size, short BLS signature, efficient signcryption method, and single sign-on solution, our work is suitable for the IoT.

Logs generated by IoT devices contain important contents and sensitive information. The logs can be stored in cloud systems for convenient management. With the management tools, it is allowed to collect, store, analyze, archive, and dispose of the log information [10]. Specific uses of the logs include device monitoring [11], user behavior analysis [12], or digital forensics [13].

The Problems
Most IoT environments adopt centralized architecture for managing log storage. It suffers from internal threats since the data can be compromised by the management staffs. Moreover, sensitive information of the logs may be revealed to unauthorized persons. The adversary can also tamper with the log for illegal purposes. The integrity of the data needs to be preserved for forensic investigations when security incidents occur [14]. Communicating parties may repudiate data ownership for their own interests or motives, which causes challenges for digital forensics [15]. In addition, the legality of collected evidences must be ensured so that it provides an effective and efficient investigation process. In heterogeneous and distributed IoT environments with various devices and sensors, these concerns become prominent.
For addressing aforesaid problems, it is essential to propose a mechanism which provides integrity, availability, and legality of the logs. Access control to the log data should also be taken into account, which ensures the confidentiality where the log can only be viewed by legitimate parties. Furthermore, the mechanism should bear a rational implementation cost.

Related Works
Blockchain is a secure decentralized database that can track, verify, and safely protect the data from tampering [16]. It provides open and transparent mechanism that does not require third-party intervention. Blockchain has successfully been used in various sectors, such as transportation systems [17], medical record management [18], and so on. The concept of combining IoT and blockchain promotes the quality of data sharing services with automatic workflows [19]. Blockchain was proposed as a security solution for IoT by various works [20][21][22]. The research topics include immutable event logs and data access management [23], sensing data transaction [24], or IoT device authentication [25]. The digital forensics in the IoT architecture can be classified into various layers consisting of cloud forensics, network forensics, and device forensics [26]. As the forensics of massive IoT devices require a lot of resources [27], legal evidences helps in improving investigation efficiency in accordance with the demand of law enforcement agencies [28].
Taguchi et al. [29] proposed a distributed management method for logs using a blockchain scheme. The method provides data tamper resistance and increases access availability. Pourmajidi and Miranskyy [30] introduced Logchain, a blockchain-based log system. Their system can avoid log tampering and provides an immutable platform for the log storage. Hang and Kim [31] designed and implemented blockchain platform for ensuring data integrity of the IoT environments. Hang and Kim focused on the integration and management of IoT data and blockchain mechanism. Whereas, the IoT forensics framework designed by Ryu et al. [13] employed the blockchain to satisfy the requirements of IoT forensics. Their work achieves data tamper proof and non-repudiation in third party-less environments. Persistence and privacy of forensic data were also assured. In their design, specific data produced by IoT devices is written into the block for facilitating evidence collection during digital forensic investigations. Aforesaid works have certain strengths that meet several functionality and security requirements. However, internal confidentiality issue was not addressed since they did not introduce access control mechanism. Moreover, the legality of the evidence preservation in their works was uncertain.

Main Contributions
Our work proposes an autonomous log storage management protocol with blockchain mechanism and access control for IoT environments. The proposed protocol allows sensor to perform the signcryption of the log data based on its access policy. With access control mechanism, only the authorized users with appropriate attributes are able to unsigncrypt the message and view the log. Each entity in the system has to sign a signature during communication process so that they can be tracked for potential forensics. We integrate blockchain mechanism and digital signature technique to simultaneously achieve various properties. The contributions made in this paper can be described in the following.

•
Autonomous model allows sensors to encrypt the logs before sending them to other entities (gateways and servers). Privacy of the logs therefore is fully protected throughout communication process. In this way, our protocol is even secure for communications via unreliable channels.
Typical application of this model is WBAN, where wearable sensors encrypt health data before sending it to coordinators and healthcare providers for specific services.
• Since legality of blockchain signature remains uncertain, whereas digital signature satisfies various requirements with legal security properties [36], we introduce the concept "signature chain" in this work. A signature chain is composed by the signatures of all communicating entities of the system including sensors, gateway and server. The integration of blockchain and signature chain achieves valuable properties: robust identity verification, data integrity, tamper proof (insider attack resistance), ownership non-repudiation, and evidence legality. Thus, our work is completely helpful to the purposes of digital forensics.
• In our design, private blockchain is employed as a storage to conveniently and efficiently store and process the signature chain and ciphertexts, with various management functions. We adopt Proof of Work (PoW) [37] as the consensus algorithm in proposed private chain, in order to achieve above-mentioned security properties. Due to its full decentralization mechanism and immutability, public blockchain is integrated in our protocol to assure the trust of the private blockchain.
• Fine-grained access control with ciphertext policy attribute-based encryption is proposed in our work. It provides internal confidentiality in which only the legitimate users with specific appropriate attributes are allows to decrypt the ciphertexts and obtain the log plaintexts.
• We use AVISPA toolset and GNY logic to formally prove security correctness of the proposed protocol. Sematic security proof further indicates that our protocol satisfies various security requirements.
• Our work employs elliptic curve with small key size, short BLS signature, and efficient signcryption method to design the protocol with single sign-on solution. Therefore, our protocol bears low computation and storage overhead, which is suitable to the IoT.

•
We provide practical implementation of the proposed protocol with specific use case, system construction and user interface.

Paper Structure
The paper is structured as follows. We present preliminaries of our work in Section 2. Section 3.1 provides system model of our work including all entities with communicating roles. Security goals are provided in Section 3.2, which are required for providing a secure communication with the proposed system model. Section 3.3 presents specific procedure and algorithms of the protocol. Section 4 presents security analysis of the proposed protocol including GNY logic, AVISPA toolset, and semantic proof. Performance experiment and analysis of the our protocol are provided in Section 5. Section 6 describes the implementation including practical procedures and system construction of our work. Finally, some concluding remarks and future works are given in Section 7 of the paper.

Linear Secret-Sharing Scheme
Linear Secret-Sharing Scheme (LSSS) proposed by Lewko and Waters [38] introduced how to use AND and OR gates to generate the matrices. LSSS consists of access policy matrix M and column vector v. The matrix M is composed by m rows and n columns, with the policy defined and stored by Boolean formula [39,40]. Whereas, the vector v is composed by s, a 1 , a 2 , . . . a n ∈ R Z p that are the randomly selected numbers, in which s is the secret value. Multiplying matrix M with vector v will derive a column vector composed by λ 1 , . . . λ n , where λ is the associated information of the secret value s. Access policy M contains a certain number of attributes. As long as users possess appropriate attributes, they can restore the secret value s.

Attribute-Based Encryption
Attribute-based encryption (ABE) was proposed by Sahai and Waters in 2005 [41]. In ABE, access policy defined by users considers various attributes. The attributes possessed by users determine whether they can meet the policy of data access. This advantage allows an efficient and flexible encryption process. ABE is categorized into two types: key policy attribute-based encryption (KP-ABE) [42,43] and ciphertext policy attribute-based encryption (CP-ABE) [44][45][46]. In the CP-ABE scheme, user's key is integrated with the attributes; and the ciphertext is associated with the access policy through the LSSS. When access policy is satisfied, the user can use the attribute key to decrypt the ciphertext. On the other hand, in the KP-ABE scheme, the user's key is associated with the access policy; and the ciphertext is integrated with the attributes. When the ciphertext meets the key's access policy, the user can decrypt the ciphertext.

Signcryption
Signcryption [47] is the combination of encryption and signature signing. The ciphertext and signature of the message are generated by performing the functions of both encryption and signature at the same time. Compared with the cumulative cost of separate encryption and signing process, this novel method is much more efficient. Signcryption method provides confidentiality, verification and non-repudiation of the given data. Attribute-based signcryption [48] combines the functions of encryption and signature on the attributes. Fine-grained access control can be associated with the signcrypted text to achieve robust message protection. This novel access control mechanism is well suited for data sharing in distributed environments. For example, users outsource their data to cloud Sensors 2020, 20, 6471 5 of 32 storage, and can effectively share the data with other parties. The users who are granted the access can effectively obtain the data from anywhere through the network.

Bilinear Map
Selects a big number q, we have the elliptic curve: E : y 2 = x 3 + ax + b mod q. Let G 1 be a multiplicative cyclic group of order n, and g, g 1 and g 2 be the generators of G 1 , a bilinear map from G 1 × G 1 to G T is a function e : G 1 × G 1 → G T . The bilinear map provides the following characteristics and assumption [45,49,50]: • Bilinear: If any two integers x, y ∈ Z p and generators g, g 1 , g 2 ∈ G 1 , then e g x 1 , g y 1 = e(g 1 , g 1 ) xy = e g y 1 , g x 1 , and e(g 1 .g 2 , g) = e(g 1 , g).e(g 2 , g).

•
Non-degenerate: There exists g 1 , g 2 ∈ G 1 such that e(g 1 , g 2 ) is the generator of G T .
• Computable: For any g 1 , g 2 ∈ G 1 , there exists a polynomial algorithm which can efficiently compute e(g 1 , g 2 ).
• Elliptic Curve Discrete Logarithm Problem (ECDLP): ECDLP is a special case of Discrete Logarithm Problem (DLP), and can be described as follows. Given g 1 , m ∈ G 1 , the problem is to find integer x ∈ Z p such that g x 1 = m.

Boneh-Lynn-Shacham Signature Scheme
Boneh-Lynn-Shacham (BLS) scheme [51] provides shorter signature length than Elliptic Curve Digital Signature Algorithm (ECDSA) [52], but with the same security level. BLS signature scheme can provide batch verification function, which allows to sign and verify multiple signatures at once. Given g 1 , G 1 , G T defined in Section 2.4, plaintexts M 1 : {0, 1} * , M 2 : {0, 1} * , and hash function H : {0, 1} * ∈ G 1 , the procedure of BLS scheme is described as follows: • Key generation: Randomly choose an integer x ∈ R Z p , let x be private key, we have Y = g 1 x is the corresponding public key.

•
Signature generation: Use hash function H and private key x to sign the plaintext M 1 and generate signature σ 1 = H(M 1 ) x .

Blockchain
Blockchain was proposed by Nakamoto in 2008 with its first application, Bitcoin [53]. Peer-to-peer (P2P) mechanism of blockchain with distributed ledger is employed to form decentralized networks. Nodes within the networks communicate with each other to confirm the validity of the transactions before they are uploaded to the blockchain. Due to a unique data structure, the content and transaction recorded in blockchain are unalterably protected. Blockchain provides decentralization [54], tamper resistance [55], and user anonymity [56]. There are three types of blockchain: public blockchain, private blockchain and consortium blockchain [57]. In public blockchain, everyone can conduct transactions, verifications and relevant contributions. It is recognized as the concept of completely decentralized open network. Whereas, private blockchain network partly achieves the decentralization since its design allows a single organization to hold central authority. Data access in private blockchain is only granted to a certain number of users based on specific purposes. The consortium blockchain Sensors 2020, 20, 6471 6 of 32 mechanism is similar to the private blockchain. The difference is consortium blockchain includes multiple organizations, which can provide business-to-business (B2B) services.

Single Sign-on
Single Sign-On (SSO) [58] provides multi-server environment that allows users to use a single password to log in multiple servers. After completing identity authentication with one sever, users can freely access the services on other severs within the network, without having to repeat authentication procedure. The benefits of SSO solution can be summarized as follows: (1) Avoids the confusion of users when they must store massive credentials at the same time in single-server environments; (2) Allows central service provider to conveniently manage the authentication information of users; and (3) Significantly reduces credential storage overhead.

The Proposed Log Storage Management Protocol with Blockchain Mechanism and Access Control
In this section, we describe system model and security goals of the proposed protocol. Thereafter, detailed procedure of our protocol is presented. Cryptographic functions and notations used in the protocol are described in Table 1.

System Model
Our system model includes 11 roles: attribute authority, SSO server, timestamp server, sensor (IoT device) and agent, gateway, blockchain server, private blockchain, public blockchain, storage cluster, and user. The attribute authority generates public and secret parameters used in entire communication process. In particular, it sends public parameters to the sensor for log signcryption. The authority also computes private attribute key and transmits it to the user for log unsigncryption. The SSO server provides single sign-on login, allowing users to use a single password to enter multiple servers in multi-server environment. The timestamp server derives timestamp parameters for the system. The sensor is a sensing device which contacts the environment, and generates the logs. The agent is installed inside the sensor, and is responsible for defining the access policy, as well as signcrypting the logs to generate ciphertexts. The gateway verifies the signature included in the ciphertexts to ensure the Sensors 2020, 20, 6471 7 of 32 correctness of the log ciphertext. Blockchain server is responsible for storing the signcrypted text in the storage cluster. Moreover, the server also generates private blocks from single signatures, and public block from multiple signatures, and then writes them into private blockchain and public blockchain respectively. The private blockchain stores signature chains and related information. The public blockchain records corresponding data from the private blockchain, and stores the batch signatures, with fully decentralized nature. The user logs in to the blockchain server through the SSO server, obtains the ciphertext, and uses the attribute private key to unsigncrypt it to view the log plaintext. The user can also verify the validity of the related information stored in private blockchain and public blockchain. System model of the proposed protocol is depicted in Figure 1.
the signcrypted text in the storage cluster. Moreover, the server also generates private blocks from single signatures, and public block from multiple signatures, and then writes them into private blockchain and public blockchain respectively. The private blockchain stores signature chains and related information. The public blockchain records corresponding data from the private blockchain, and stores the batch signatures, with fully decentralized nature. The user logs in to the blockchain server through the SSO server, obtains the ciphertext, and uses the attribute private key to unsigncrypt it to view the log plaintext. The user can also verify the validity of the related information stored in private blockchain and public blockchain. System model of the proposed protocol is depicted in Figure 1.
Signature chain is composed by the signatures signed by the sensor, the gateway and the server in each communication session. Data in private blockchain is signed using two types of signature schemes including BLS and ECDSA. Each block contains a single signature chain. These chains are immutably stored in blockchain for further security purposes. Figure 2 depicts the design of private blockchain and signature chain of our work.  Signature chain is composed by the signatures signed by the sensor, the gateway and the server in each communication session. Data in private blockchain is signed using two types of signature schemes including BLS and ECDSA. Each block contains a single signature chain. These chains are immutably stored in blockchain for further security purposes. Figure 2 depicts the design of private blockchain and signature chain of our work.

Security Goals
Security problems are always big concerns in any information systems. The proposed system model includes various parties in a public communication environment. External invasion and security attacks should also be considered for providing a high security environment. We expect that our protocol can satisfy the following security requirements.

•
Secure decryption key: After the sensor signcrypts the logs, the user attempts to compute the decryption key to decrypt the ciphertext and access the logs. Only legitimate user possessing appropriate attributes is able to compute the correct key.

•
Robust verification: The digital signature signed by the sensor makes sure that the log data is truly produced and transmitted by the sensor itself. Any parties participating in the communication can verify the validity of the signature. • Data unforgeability: Only the sensor with its own private key is able to sign the message. We desire to warrant that the signcryption key of the sensor is kept secret to the sensor only, during communication process. In this way, the adversary cannot forge the signature and impersonate the sensor. • Data tampering resistance: The signatures may be modified for obstruction purposes. In addition, the signer may re-sign the message to tamper with its data. These issues should be addressed so that security properties of digital signature are guaranteed. • Data confidentiality: The log data must be kept confidential to the legal parties under any circumstances. Users within the system are allowed to access the logs only if they possess required attributes. • Non-repudiation: Once the logs are signed, signers cannot repudiate them for any own interests. This property is helpful to digital forensic investigations.

•
Data integrity: This property makes sure that the logs must be originally sent by the sensor without any modifications to its contents.

•
Perfect forward secrecy: This security goal is required for the long-term decryption key. It ensures that if the adversaries successfully calculate the current decryption key, they still cannot use it to compromise the logs in previous communications sessions.

Security Goals
Security problems are always big concerns in any information systems. The proposed system model includes various parties in a public communication environment. External invasion and security attacks should also be considered for providing a high security environment. We expect that our protocol can satisfy the following security requirements.

•
Secure decryption key: After the sensor signcrypts the logs, the user attempts to compute the decryption key to decrypt the ciphertext and access the logs. Only legitimate user possessing appropriate attributes is able to compute the correct key.
• Robust verification: The digital signature signed by the sensor makes sure that the log data is truly produced and transmitted by the sensor itself. Any parties participating in the communication can verify the validity of the signature.
• Dataunforgeability: Only the sensor with its own private key is able to sign the message. We desire to warrant that the signcryption key of the sensor is kept secret to the sensor only, during communication process. In this way, the adversary cannot forge the signature and impersonate the sensor.
• Datatampering resistance: The signatures may be modified for obstruction purposes. In addition, the signer may re-sign the message to tamper with its data. These issues should be addressed so that security properties of digital signature are guaranteed.
• Data confidentiality: The log data must be kept confidential to the legal parties under any circumstances. Users within the system are allowed to access the logs only if they possess required attributes.
• Non-repudiation: Once the logs are signed, signers cannot repudiate them for any own interests. This property is helpful to digital forensic investigations.
• Data integrity: This property makes sure that the logs must be originally sent by the sensor without any modifications to its contents.
• Perfect forward secrecy: This security goal is required for the long-term decryption key. It ensures that if the adversaries successfully calculate the current decryption key, they still cannot use it to compromise the logs in previous communications sessions.

Procedure of the Proposed Protocol
Communication in the proposed protocol is carried out including 13 phases: initialization phase, device registration phase, SSO registration phase, SSO login phase, SSO password generation phase, user registration phase, log signcryption phase, log verification phase, private block calculation phase, private block verification phase, log unsigncryption phase, public block calculation phase and public block verification phase.

System Initialization Phase
In initialization phase, the attribute authority generates public and secret parameters used in entire system. The attribute authority selects a big number q, and determine the elliptic curve: E : y 2 = x 3 + ax + b mod q. It then generates a cyclic group G 1 and bilinear map e : G 1 × G 1 → G T . g is set as the generator of G 1 . Next, a set of system attributes is determined by u s = {att 1 , att 2 , . . . , att x }. The authority selects the corresponding random numbers {Q 1 , Q 2 , . . . , Q x } ∈ R G 1 , based on attribute set u s , and chooses a secure one-way hash function H : {0, 1} * ∈ G 1 . It randomly selects α, β ∈ R Z q , and compute B = g β and public key Y = e(g, g) α . Finally, the authority generates public parameter PP = (g, B, Y, H, Q x , e, G 1 , G T ) and secret parameter MSK = (α, β, u s ). Specific steps of this phase are described in Algorithm 1.

1:
Select a big number q, and determine the elliptic curve: E : Generate a cyclic group G 1 and bilinear map e : Set g as the generator of G 1 . 4: Determine system attribute set u s = {att 1 , att 2 , . . . , att x }.

SSO Registration Phase
In this phase, the user U i uses a smart card to register with the SSO server for obtaining multiple services. SSO registration procedure is provided in Algorithm 2 as follows. The user U i enters SID i and SPW i into smart card. The smart card generates a random number r i , and computes The SSO sever then stores r i and A i . Algorithm2: SSO registration.

1:
U i enters SID i and SPW i into smart card.

2:
Smart card generates r i .

3: Smart card computes
SSO sever stores r i and A i .

SSO Login Phase
The user U i enters SID i and SPW i into SSO sever for verifying his/her legitimacy. The user U i enters SID i and SPW i into the SSO server. The SSO server computes A i = H(SPW i ) ⊕ H(r i SID i ). It then compares A i and A i , in order to verify legitimacy of the user U i . Procedure of this phase is presented by Algorithm 3.

1:
U i enters SID i and SPW i . 2: SSO server computes SSO server compares A i and A i . 4: if above check holds, then output True, and confirm legitimacy of U i . 5: otherwise, output False, and terminate the login.

SSO Password Generation Phase
The use U i enters SID i , SPW i and ID i so that the server can generate an SSO password. In this way, the user U i can obtain services from multiple servers using this single password. The user U i enters SID i , SPW i and ID i into SSO server. The SSO server generates PW i from SID i , SPW i and ID i . Procedure of this phase is described by Algorithm 4.

1:
U i enters SID i , SPW i and ID i into SSO server.

Device Registration Phase
In this phase, the sensor i registers with the attribute authority for further communication. The sensor and the authority perform necessary steps for device registration, as presented in Algorithm 5. The sensor i sends DID i to the attribute authority. The authority verifies DID i , then sends public parameter PP to the sensor i .

1:
Sensor i sends DID i to attribute authority.

2:
Attribute authority verifies DID i .

3:
Attribute authority sends PP to sensor i .

User Registration Phase
The user U i uses his/her identity ID i to register and obtain the attribute private key from the attribute authority. This procedure is performed by the attribute authority, as specified in Algorithm 6. The user U i first sends his/her identity ID i to the attribute authority. Upon the received message, the attribute authority verifies ID i . It then randomly chooses t ID i ∈ R Z q , and uses g, α, β, and t ID i to compute K i , L i = g t ID i and . The authority generates attribute private key SK ID i = (K i , L i , K i j ), and sends SK ID i to the user U i .

Log Signcryption Phase
In this phase, the sensor i is allowed to signcrypt the log, based on attribute-based access policy, Boolean formula BF and public parameters PP. The sensor i performs specific steps in Algorithm 7 for the log signcryption procedure. It sets LSSS matrix m e by Boolean formula BF, and randomly generates random number r j ∈ R Z q (∀ j ∈ x) and a secret vector The sensor i generates ciphertext CT = σ CT , C, C j , C , D j , m e , IP IoT , t CT , and then sends it to the gateway. Finally, δ IoT = (σ IoT , IP IoT , t IoT ) is stored by the sensor i .

1:
Set LSSS matrix m e by BF.

Log Verification Phase
The gateway verifies the validity of the signatures and the ciphertext CT, based on public parameters PP. If the verifications are valid, the gateway will send it to the blockchain server. This phase is performed by the gateway with Algorithm 8. The gateway checks e(h, Y .x C )e(σ, g) and ECDSA(δ IoT , σ CT ). If the checks hold, it sends ciphertext CT to the blockchain server. The ciphertext is then stored at cluster storage. The gateway computes signature σ GW = ECDSA(σ CT , σ IoT , IP GW , t GW ), sets δ GW = (σ GW , IP GW , t GW ), and stores δ GW .
if above checks hold, then continue with step 5.

4:
otherwise, terminate the session.5: Send CT to blockchain server, CT is then stored in cluster storage.

Log Unsigncryption Phase
In log unsigncryption phase, the user U i is allowed to unsigncrypt the ciphertext CT to view the log M, using private key SK ID i (with appropriate attributes) and public parameter PP. The user U i uses Algorithm 9 to complete this procedure. Parameter w i is first restored from the matrix m e with appropriate attributes. The user U i then uses parameters C, C , D j and private key is computed for checking e(h, Y .x C )e(σ, g) based on parameters g, Y, C and C . At last, the user U i uses Y s to decrypt log ciphertext and obtain the log by M = C.Y s−1 .

1:
Restores w i from m e with appropriate attributes:

2:
Use C, C , D j and SK ID i to compute decryption key:

4:
Use g, Y, C and C to Veri f y : e(h, Y . x C )e(σ CT , g).

5:
if above check holds, then continue with step 7. 6: otherwise, terminate the session. 7: Use Y s to decrypt C and obtain M = C.Y s−1 .

Private Block Calculation Phase
Based on the ciphertext CT and some other information, the blockchain server calculates private block data, then writes it to the blockchain. At first, the server retrieves previous hash from the private blockchain, and verifies ECDSA signature σ GW .
It computes signature σ Srv = ECDSA(σ CT , σ GW , IP Srv , t Srv ), and sets δ Srv = (σ Srv , IP Srv , t Srv ) and δ CT = (σ CT , IP Srv , t CT ). The initial Nonce value is set as 0. The server then iteratively compute H(Nonce PreviousHash δ Srv δ GW δ IoT δ CT OptionalFields OtherFields), which must be smaller than the Di f f iculty level. It sets Nonce = Nonce + 1 if above check does not hold, and re-compute the hash. The computing is completed if above condition holds. Block data PriB = (δ Srv , δ GW , δ IoT , δ CT , Nonce, Di f f iculty, Optional Fields is generated and written to the private blockchain. Finally, the server receives a corresponding block number PriBlockNo n . Private blockchain calculation procedure is further specified in Algorithm 10.

Private Block Verification Phase
In this phase, the user U i verifies the validity of the private block PriB. Specific steps of private block verification are performed by the user U i with Algorithm 11. The user U i verifies whether H(Nonce PreviousHash δ Srv δ GW δ IoT δ CT OptionalFields OtherFields) < Di f f iculty. The validity of ECDSA signatures (δ IoT , σ CT ), (δ GW , σ CT ) and (δ Srv , σ CT ), and e(h, Y .x C )e(σ CT , g) are also verified. The system outputs True if above verifications hold, otherwise outputs False.

Public Block Calculation Phase
The blockchain sever computes batch signature from multiple signatures, and write it to public blockchain. In this. way, credibility of the signatures is enhanced with immutability feature. The procedure is performed by the blockchain server with Algorithm 12 as follows. The server retrieves block number PriBlockNo n from the corresponding block PriB n , and multiple signatures σ CT n from multiple private blocks PriB n . Batch signature BSig = σ CT 1 σ CT 2 . . . σ CT n is computed to generate public block PubB = (PriBlockNo n , BSig, Optional Fields). Next, the server writes PubB to the public blockchain, and receives the corresponding block number PubBlockNo n .

Public Block Verification Phase
In this phase, the user U i verifies the batch verification of data recorded in public blockchain, based on CT n , PubB and PP. Algorithm 13 is performed by the user U i to complete this procedure. The user U i confirms if PriBlockNo n is available on the private chain, then obtains the corresponding blocks PriB n . Next, the user U i verifies whether BSig matches the signatures in the private blocks PriB n . Value h n = H(C n ) is computed based on n log ciphertext C n . Finally. the user U i verifies the validity of the batch signature: e(h n , Y .xn C n )e(BSig, g n ). The system outputs True, meaning the verification is successful if the check holds, otherwise outputs False.

1:
Confirm if PriBlockNo n is available on private blockchain.

5:
Compute h n = H(C n ), based on n log ciphertext C n .

Security Analysis
In this section, we use AVISPA toolset and GNY logic to verify security correctness of the proposed protocol. In addition, we prove that our protocol meets various security requirements based on the semantic proof.

Protocol Simulation Using AVISPA Toolset
We verify the security properties of the proposed protocol by employing Automated Validation of Internet Security Protocols and Applications (AVISPA) [59]. AVISPA tool uses HLPSL [60] as its formal language, and integrates different back-ends in the verification techniques. The back-ends includes On-the-fly Model-Checker (OFMC), Constraint Logic based Attack Searcher (CL-AtSe), SAT-based ModelChecker (SATMC), and Tree Automata based on automatic approximations for the analysis of security protocols (TA4SP). However, the SATMC and TA4SP back-ends are not frequently used since they cannot verify the protocols using algebraic properties of modular exponentiation and XOR operator. In this simulation, AVISPA tool is integrated with Security Protocol Animator (SPAN) for providing a user-friendly application interface.
In our protocol, single signature verifications conducted by the gateway, the user and the blockchain sever are identical. We therefore only simulate the verification of the user in the log unsigncryption phase. Moreover, since the gateway and the sever just merely receives and verifies the signature, and they do not make any changes to the signature, we assume that the user directly receives signature from the sensor. We use the similar arguments of single signature verification for verifying the correctness of the batch signature.
HLPLS codes in the simulation was specified with three roles: authority (A), sensor (S), and user (U). The symmetric key Kau is used to protect the information in user registration phase. Based on our protocol, (α, β, u s ) are secret keys of the authority, but for simplicity of the simulation, we only include α. Since AVISPA only support three types of operators (concatenation, exclusive or, and exponentiation), the multiplication and paring function can be performed as hash functions. We also assume ECDSA and inv(ECDSA) are public key and private key respectively, for performing ECDSA algorithms. Specific HLPSL specifications of the user, the authority, and the sensor are provided in Figures 3-5

Security Analysis
In this section, we use AVISPA toolset and GNY logic to verify security correctness of the proposed protocol. In addition, we prove that our protocol meets various security requirements based on the semantic proof.

Protocol Simulation Using AVISPA Toolset
We verify the security properties of the proposed protocol by employing Automated Validation of Internet Security Protocols and Applications (AVISPA) [59]. AVISPA tool uses HLPSL [60] as its formal language, and integrates different back-ends in the verification techniques. The back-ends includes On-the-fly Model-Checker (OFMC), Constraint Logic based Attack Searcher (CL-AtSe), SAT-based ModelChecker (SATMC), and Tree Automata based on automatic approximations for the analysis of security protocols (TA4SP). However, the SATMC and TA4SP back-ends are not frequently used since they cannot verify the protocols using algebraic properties of modular exponentiation and XOR operator. In this simulation, AVISPA tool is integrated with Security Protocol Animator (SPAN) for providing a user-friendly application interface.
In our protocol, single signature verifications conducted by the gateway, the user and the blockchain sever are identical. We therefore only simulate the verification of the user in the log unsigncryption phase. Moreover, since the gateway and the sever just merely receives and verifies the signature, and they do not make any changes to the signature, we assume that the user directly receives signature from the sensor. We use the similar arguments of single signature verification for verifying the correctness of the batch signature.
HLPLS codes in the simulation was specified with three roles: authority (A), sensor (S), and user (U). The symmetric key Kau is used to protect the information in user registration phase. Based on our protocol, ( , , ) are secret keys of the authority, but for simplicity of the simulation, we only include . Since AVISPA only support three types of operators (concatenation, exclusive or, and exponentiation), the multiplication and paring function can be performed as hash functions. We also assume ECDSA and inv(ECDSA) are public key and private key respectively, for performing ECDSA algorithms. Specific HLPSL specifications of the user, the authority, and the sensor are provided in          In addition, Figure 6 provides the specification of the session role where its composition consisting of all main roles is specified. Environment role illuminated in Figure 7 specifies all relevant components within the communication environment including symmetric keys, functions, protocol id, and intruder knowledge. In simulated environment, we can see that the intruder in turn replaces the roles of the authority, the sensor and the user in respective sessions in which, he/she attempts to compromise the simulated system. We consider four secrecy goals and one authentication goal described in the following: • "secrecy_of idi" represents the identity ID i that the user uses to register with the authority via a secure channel, it is kept secret to the user and the authority.
• "secrecy_of sk" represents SK ID i that the authority sends to the user, it is also kept secret to the user and the authority.
• "secrecy_of alpha" represents the secret value α, it is kept secret to the authority.
• "secrecy_of ss" represents the secret key s, it is kept secure to the sensor.
• "authentication_on ss": the user authenticates the sensor on s.
Sensors 2020, 20, x FOR PEER REVIEW 17 of 32 In addition, Figure 6 provides the specification of the session role where its composition consisting of all main roles is specified. Environment role illuminated in Figure 7 specifies all relevant components within the communication environment including symmetric keys, functions, protocol id, and intruder knowledge. In simulated environment, we can see that the intruder in turn replaces the roles of the authority, the sensor and the user in respective sessions in which, he/she attempts to compromise the simulated system. We consider four secrecy goals and one authentication goal described in the following: • "secrecy_of idi" represents the identity that the user uses to register with the authority via a secure channel, it is kept secret to the user and the authority.
• "secrecy_of sk" represents that the authority sends to the user, it is also kept secret to the user and the authority.
• "secrecy_of alpha" represents the secret value , it is kept secret to the authority. • "secrecy_of ss" represents the secret key , it is kept secure to the sensor.   After defining certain communication sessions in environment role, we execute the tool to check the security correctness. The results of OFMC backend and CL-AtSe backend are shown in Figure 8. We claim that the proposed protocol is provably secure under AVISPA simulation. In addition, Figure 6 provides the specification of the session role where its composition consisting of all main roles is specified. Environment role illuminated in Figure 7 specifies all relevant components within the communication environment including symmetric keys, functions, protocol id, and intruder knowledge. In simulated environment, we can see that the intruder in turn replaces the roles of the authority, the sensor and the user in respective sessions in which, he/she attempts to compromise the simulated system. We consider four secrecy goals and one authentication goal described in the following: • "secrecy_of idi" represents the identity that the user uses to register with the authority via a secure channel, it is kept secret to the user and the authority.
• "secrecy_of sk" represents that the authority sends to the user, it is also kept secret to the user and the authority.
• "secrecy_of alpha" represents the secret value , it is kept secret to the authority. • "secrecy_of ss" represents the secret key , it is kept secure to the sensor.   After defining certain communication sessions in environment role, we execute the tool to check the security correctness. The results of OFMC backend and CL-AtSe backend are shown in Figure 8. We claim that the proposed protocol is provably secure under AVISPA simulation. After defining certain communication sessions in environment role, we execute the tool to check the security correctness. The results of OFMC backend and CL-AtSe backend are shown in Figure 8. We claim that the proposed protocol is provably secure under AVISPA simulation.

Logical Analysis Using GNY Logic
This sub-section proves security completeness and correctness of our proposed protocol through Gong-Needham-Yahalom (GNY) logic [61]. For our protocol, the analysis consists of two phases in the logic sequence: message freshness verification and message origin verification. Based on GNY logic, the assumptions and logical rules of our protocol are described in Table 2 and Table 3 respectively [1,62]. ∋

Logical Analysis Using GNY Logic
This sub-section proves security completeness and correctness of our proposed protocol through Gong-Needham-Yahalom (GNY) logic [61]. For our protocol, the analysis consists of two phases in the logic sequence: message freshness verification and message origin verification. Based on GNY logic, the assumptions and logical rules of our protocol are described in Tables 2 and 3 respectively [1,62].  Main communication of our protocol can be presented in logic as follows.
sensor i → U i : h Y . x s , (M)e(g, g) αs , g Bλ e Q j −r j , g s , g r j , m e , IP IoT , t CT sensor i → gateway : h Y . x s , (M)e(g, g) αs , g Bλ e Q j −r j , g s , g r j , m e , IP IoT , t CT Specific phases and corresponding goals of the protocol are described in the following.
• Phase 1: Message freshness authentication, proving the authenticity of the message.
Goal 1: Other than the authority, only the user U i can read the content of the message transmitted by the sensor i . Goal 1 (G1) is described as follows.
The gateway can verify that only the sensor i can generate the message received by the gateway. Goal 3 (G3) is described as follows.
Gateway |≡ sensor i | ∼ h Y . x s , (M)e(g, g) αs , g Bλ e Q j −r j , g s , g r j , m e , IP IoT , t CT Based on the assumptions and logical rules, we have the protocol achieve above goals as follows.
Since U i knows of the message, we have that.
According to (T 1 ), we have that.
According to (2), (A 1 ) and (T 3 ), the user U i can compute secret key Y s and use it to decrypt C = MY s , we have that.
According to (3) and (P), we have that.
U i h Y . x s , (M)e(g, g) αs , g Bλ e Q j −r j , g s , g r j , m e , IP IoT , t CT , Based on (4), (A 2 ) and (A 3 ), h Y . x s is truly recognizable. Therefore, according to (A 4 ) and (R), we have that.
U i ≡ ∅ h Y . x s , (M)e(g, g) αs , g Bλ e Q j −r j , g s , g r j , m e , IP IoT , t CT ), Based on (5) , and (F), G2 is achieved. Using similar arguments of G2, we realize G3. As a result, the proposed protocol realizes all goals G1, G2 and G3.

Semantic Proof
Our proposed protocol provides secure decryption key, signature verification and data integrity, signature unforgeability, data confidentiality, non-repudiation, tamper proof, and perfect forward secrecy. The specific semantic security proof of the protocol is presented in the following.

•
Secure decryptionkey: Based on ECDLP, the adversary cannot retrieve the secret values s from C . The secret value α is also hidden in K i , and K i is even kept secret to the user and the authority only. Therefore, the adversary is not able to obtain g s and g α for computing the decryption key Y s = e(g, g) sα .
The key is successfully computed only when the legitimate user performs correct pairing operation with appropriate attributes. Thus, we claim the proposed protocol achieves secure decryption key.
• Robustverification and data integrity: In our protocol, the signature of the ciphertext is verified to assure the authenticity of the log. The verification correctness of single signature σ CT 1 is proved as follows.
Suppose there have two signatures for the batch signing, the following equation proves the correctness of batch signature verification (including σ CT 1 and σ CT 2 ).
Therefore, the signature is verifiably correct. After verifying that the log and its signature is originally sent and signed by the sensor, the integrity is achieved. Thus, the conclusion is established.
• Signatureunforgeability: If the adversary wants to forge the signature σ = h Y .x s , he must obtain the correct s. However, as stated, the value s is protected by ECDLP. The adversary therefore is not able to compute s for forging signature σ. So, our work achieves signature unforgeability.
• Dataconfidentiality: If the adversary wants to restore the log M from the ciphertext, he/she must obtain SK ID i =(K i , L i , K i j ) and compute Y s to unsigncrypt C. However, only the user who has registered with the authority possesses correct attributes and the key SK ID i . As stated, the security of the decryption key Y s is also guaranteed. Moreover, the adversary does not know of MSK = (α, β, u s ) to compromise the system. Thus, the confidentiality of the logs is fully achieved.

•
Non-repudiation and tamper resistance: During the communication in our protocol, private key s is only known to the sensor. Therefore, the sensor cannot repudiate the signature signed by itself.
The signature is furthermore uploaded to public blockchain. Once recorded, it is not possible for block data to be altered retroactively. In this way, the signature cannot be tampered with. Therefore, we claim non-repudiation and data tampering resistance in the proposed protocol.
• Perfect forward secrecy: In log signcryption phase, the sensor chooses the key s to compute the ciphertext and generate the decryption key Y s . Since s is a randomly selected, the key Y s is computed as a nonce. Therefore, even though the adversary has obtained the decryption key of the current session, he/she cannot recover keys of the past communication sessions. Thus, perfect forward secrecy is achieved in our protocol.

Comparison with Related Works
We furthermore indicate contributions of this paper by a comparative study of our work and recently published works discussed in Section 1.2. The comparison is described in Table 4. Symbol √ denotes the protocol achieves the corresponding property, and symbol × denotes the property is not provided by the protocol. Besides, symbol -denotes the property is not available in the protocol. The results show that the proposed protocol satisfies all essential requirements of security and functionality. Especially, only our protocol provides signature chain with evidence legality, which is useful for digital forensic investigations. Public-private blockchain and signcryption method are also not available in all others works except ours. In addition, autonomous model is only introduced in our work, and Hang and Kim [31]'s work.

Performance Analysis
In this section, we analyze performance of the proposed protocol based on computation cost. Computation times of major cryptographic functions and operations used in the proposed protocol are defined as follows.
• T E : Time of performing an exponentiation operation in G 1 .
• T BP : Time of performing a bilinear paring operation.
• T H : Time of performing a hash function.
• T ECDSA_Gen : Time of performing an ECDSA generation algorithm.
• T ECDSA_Veri : Time of performing an ECDSA verification algorithm.
Due to SSO solution, computation cost of our protocol is independent of the number of servers. Since generating and verifying the ECDSA are performed using private key and public key, we assume their computation costs are similar to asymmetric encryption and decryption algorithms respectively. Suppose finding the nonce value in private blockchain (computing the hash) is straightforward. As shown in Table 5, total cost of the proposed protocol is (5mT E + 2m(n + 1)T H + (2mni + 5mn + 2m)T BP + 3mT ECDSA_Gen + (3mn + 2m)T ECDSA_Veri ). Especially, the sensors consume only (5T E + T H + T ECDSA_Gen ) for signcrypting a single log. Based on the data of Table 5, we further conduct experiments of protocol performance with two scenarios: (a) a single user with i attributes signcrypts a single log, and (b) a single user with certain number of attributes (suppose i = 3) signcrypts m logs. In the former scenario (depicted in Figure 9a), the cost is slightly increased when i increases. In the latter scenario (depicted in Figure 9b), when m increases, the cost is significantly increased. only (5 + + _ ) for signcrypting a single log. Based on the data of Table 5, we further conduct experiments of protocol performance with two scenarios: (a) a single user with attributes signcrypts a single log, and (b) a single user with certain number of attributes (suppose = 3) signcrypts logs. In the former scenario (depicted in Figure  9a), the cost is slightly increased when increases. In the latter scenario (depicted in Figure 9b), when increases, the cost is significantly increased. It is observed that our protocol bears a reasonable cost with various components and a lot of functionalities. Moreover, it is important to note that the proposed protocol is designed with ECC small key size, rapid BLS signature, signcryption method, and SSO solution. Our work therefore bears low computation and storage cost, and is well suited for the IoT.  It is observed that our protocol bears a reasonable cost with various components and a lot of functionalities. Moreover, it is important to note that the proposed protocol is designed with ECC small key size, rapid BLS signature, signcryption method, and SSO solution. Our work therefore bears low computation and storage cost, and is well suited for the IoT.

Implementation
Our implementation simulates log protection of air conditioner Sensor 1 in the context of a laboratory in Chang Gung University (Taiwan). Sensor 1 is allowed to signcrypt its log based on an access policy. Attributes generated by the attribute authority including Chang Gung University, Department of Information Management, Professor and Student are set to att 1 , att 2 , att 3 and att 4 respectively. User U 1 attempts to access the log produced by Sensor 1 . The user is able to view the log only if he/she possesses appropriate attributes. We include practical implementation and system construction in the following sub-sections.

Practical Procedure of the Proposed Protocol
Access policy of the sensors are determined with Boolean formula in the beginning. The access policy of Sensor 1 is illuminated in Figure 10.

Implementation
Our implementation simulates log protection of air conditioner in the context of a laboratory in Chang Gung University (Taiwan).
is allowed to signcrypt its log based on an access policy. Attributes generated by the attribute authority including Chang Gung University, Department of Information Management, Professor and Student are set to , , and respectively. User attempts to access the log produced by . The user is able to view the log only if he/she possesses appropriate attributes. We include practical implementation and system construction in the following sub-sections.

Practical Procedure of the Proposed Protocol
Access policy of the sensors are determined with Boolean formula in the beginning. The access policy of is illuminated in Figure 10.  , and is uploaded to the public blockchain. Thereafter, the sever can obtain the block number generated by the pubic blockchain. The procedure is performed by Algorithm 12. In public block verification phase, the public block data , the At first, the authority initializes the corresponding public parameter PP = g, B, Y, H, Q 1 , Q 2 , Q 3 , Q 4 , e, G 1 , G T , and secret parameter MSK = α, β, u s . Sensor 1 uses its identity DID 1 to register with the attribute authority and obtains PP. The user U 1 registers, logs in, and obtains SSO password from the SSO server for accessing specific blockchain server. In this simulation, the user U 1 possesses three attributes: att 1 , att 2 and att 3 . In the user registration phase, the attribute authority performs the Algorithm 6 to compute the secret key SK ID 1 = (K 1 , L 1 , K 1 1 , K 1 2 , K 1 3 ), and send it to the user U 1 . Based on attribute-based access policy BF = "((att 3 OR att 4 ) AND att 2 ) AND att 1 ", Sensor 1 uses Algorithm 7 to perform signcryption procedure. It then generates CT 1 =(σ CT 1 , C , C 1 , C 2 , C 3 , D 1 , D 2 , D 3 , C CT 1 , IP IoT , t CT ) with (m 1 , ρ(1))(m 2 , ρ(2))(m 3 , ρ(3)) and δ 1 IoT = σ 1 IoT , IP IoT , t 1 IoT . The gateway verifies validity of the ciphertext CT 1 , sends it to the blockchain server, and stores the signature δ 1 GW = σ 1 GW , IP GW , t 1 GW after performing Algorithm 8. the user U 1 performs Algorithm 9 to compute the correct key Y s based on the key SK ID 1 with appropriate attributes. Thus, the user U 1 is able to unsigncrypt the ciphertext CT 1 and view the log M 1 .
In private block calculation phase, based on the ciphertext CT 1 and the previous hash retrieved from the private blockchain, the blockchain server generates block PriB 1 = Nonce, δ 1 CT , δ 1 Srv , δ 1 GW , δ 1 IoT , PreviousHash, Di f f iculty, OptionalFields, OtherFields , and upload it to the chain. This procedure is conducted by Algorithm 10. Thereafter, the server obtains the block number PriBlockNo 1 generated by the private blockchain. For verifying the validity of the block data PriB 1 , the user U 1 performs Algorithm 11. Suppose we have private block PriB 2 generated by the similar procedures. In public block calculation phase, the server then calculates batch signature BSig 1 = σ CT 1 σ CT 2 . Block data PubB 1 is then calculated by PubB 1 = (BSig 1 , PriBlockNo 1 , PriBlockNo 2 ), and is uploaded to the public blockchain. Thereafter, the sever can obtain the block number PubBlockNo 1 generated by the pubic blockchain. The procedure is performed by Algorithm 12. In public block verification phase, the public block data PubB 1 , the ciphertexts CT 1 , CT 2 , and public parameter PP are retrieved. Based on these parameters, the user U 1 performs Algorithm 13 to verify validity of the uploaded logs.

System Construction
In this sub-section, we construct a system deployment for the proposed protocol. The development environment and system interface of our construction are specifically provided in the following. Air conditioner sensor YW-51GJ is used as the device of our simulation. The mainboard and the sensor are integrated and assembled in a box so that sensor can contact the ambient air. Overview of our setting is shown in Figure 11.

System Construction
In this sub-section, we construct a system deployment for the proposed protocol. The development environment and system interface of our construction are specifically provided in the following. Air conditioner sensor YW-51GJ is used as the device of our simulation. The mainboard and the sensor are integrated and assembled in a box so that sensor can contact the ambient air. Overview of our setting is shown in Figure 11. • Blockchain platform: We employ Hyperledger Fabric v1.0 for private blockchain. This framework provides development foundation, modularity, scalability, and security for the simulated system. We use open source platform of the Ethereum for public blockchain. Smart contract can be fully written and published on Ethereum to develop diversified applications. In this regard, an account with virtual currency is created with Metamask wallet for data transaction. In addition, the contract is written into blockchain through Infura, an Ethereum Figure 11. Setting of our implementation.
• Blockchain platform: We employ Hyperledger Fabric v1.0 for private blockchain. This framework provides development foundation, modularity, scalability, and security for the simulated system. We use open source platform of the Ethereum for public blockchain. Smart contract can be fully written and published on Ethereum to develop diversified applications. In this regard, an account with virtual currency is created with Metamask wallet for data transaction. In addition, the contract is written into blockchain through Infura, an Ethereum application programming interface (API).
• Kubernetes: We use Kubernetes as the platform, providing microservices for data management, deployment, and expansion. Kubernetes is compatible to all OS platforms, which provides the proper use of system performance. In our simulation, private blockchain is installed with Kubernetes version 1.13.4.

•
Programming language: Languages used in our system includes Golang, HTML and Javascript. Golang library package was developed by Ben Lynn, who developed the library from the original Pairing-Based Cryptography (PBC) written in C language. According to the recommendation of NIST, the selected key length of ECC for security strength is 224-bit type.

System Interface
The device can be configured as an agent with related settings. The configuration file includes agent IP address, server IP address, server port, and agent type. In addition, the cryptographic module supports AES, NTRU, RSA and ABSE, based on the choice of specific cryptosystem. Brief description of device configuration is provided in Figure 12.
• Kubernetes: We use Kubernetes as the platform, providing microservices for data management, deployment, and expansion. Kubernetes is compatible to all OS platforms, which provides the proper use of system performance. In our simulation, private blockchain is installed with Kubernetes version 1.13.4.

•
Programming language: Languages used in our system includes Golang, HTML and Javascript. Golang library package was developed by Ben Lynn, who developed the library from the original Pairing-Based Cryptography (PBC) written in C language. According to the recommendation of NIST, the selected key length of ECC for security strength is 224-bit type.

System Interface
The device can be configured as an agent with related settings. The configuration file includes agent IP address, server IP address, server port, and agent type. In addition, the cryptographic module supports AES, NTRU, RSA and ABSE, based on the choice of specific cryptosystem. Brief description of device configuration is provided in Figure 12. The user logs in to the SSO sever using his/her password and smart card. After SSO login, the user has to make another registration with the blockchain sever. To this end, the user enters main identity, password and an additional identity "m0644013" to register with the server of Chang Gung university, named "cgu_blockchain". SSO password is generated in this registration. Figure 13 shows a registered account with its credential generated by the SSO server for targeted service. Using the account generated by the SSO server, the user can log in to the server "cgu_blockchain".  The user logs in to the SSO sever using his/her password and smart card. After SSO login, the user has to make another registration with the blockchain sever. To this end, the user enters main identity, password and an additional identity "m0644013" to register with the server of Chang Gung university, named "cgu_blockchain". SSO password is generated in this registration. Figure 13 shows a registered account with its credential generated by the SSO server for targeted service. Using the account generated by the SSO server, the user can log in to the server "cgu_blockchain". application programming interface (API).
• Kubernetes: We use Kubernetes as the platform, providing microservices for data management, deployment, and expansion. Kubernetes is compatible to all OS platforms, which provides the proper use of system performance. In our simulation, private blockchain is installed with Kubernetes version 1.13.4.

•
Programming language: Languages used in our system includes Golang, HTML and Javascript. Golang library package was developed by Ben Lynn, who developed the library from the original Pairing-Based Cryptography (PBC) written in C language. According to the recommendation of NIST, the selected key length of ECC for security strength is 224-bit type.

System Interface
The device can be configured as an agent with related settings. The configuration file includes agent IP address, server IP address, server port, and agent type. In addition, the cryptographic module supports AES, NTRU, RSA and ABSE, based on the choice of specific cryptosystem. Brief description of device configuration is provided in Figure 12. The user logs in to the SSO sever using his/her password and smart card. After SSO login, the user has to make another registration with the blockchain sever. To this end, the user enters main identity, password and an additional identity "m0644013" to register with the server of Chang Gung university, named "cgu_blockchain". SSO password is generated in this registration. Figure 13 shows a registered account with its credential generated by the SSO server for targeted service. Using the account generated by the SSO server, the user can log in to the server "cgu_blockchain".  If an administrator enters the system, he/she can see the blockchain status and overall service through a monitoring interface. The interface is described in Figure 14. Table providing information of registered devices is also shown in Figure 15. The devices signcrypt the log and uploads it to blockchain server. Int. J. Mol. Sci. 2020, xx, 5 3 of 7   In terms of attribute setting, the attribute authority is allowed to add or delete the attributes, in order to initialize the system. In this way, the authority can determine attributes for specific users, and allows them to obtain their attributes during user registration phase.
When the users log in to the system, they can click on the link within private blockchain allocated at the bottom of the monitoring interface (shown in Figure 16) to see block data. The detailed information of private blockchain is provided in Figure 17. In addition, the users (including the administrator and the users who possesses appropriate attributes) can also view the log data at the bottom of this interface. As shown in Figure 17, the log data produced by the sensor includes dust, temperature, humidity, and atmospheric carbon dioxide.  In terms of attribute setting, the attribute authority is allowed to add or delete the attributes, in order to initialize the system. In this way, the authority can determine attributes for specific users, and allows them to obtain their attributes during user registration phase.
When the users log in to the system, they can click on the link within private blockchain allocated at the bottom of the monitoring interface (shown in Figure 16) to see block data. The detailed information of private blockchain is provided in Figure 17. In addition, the users (including the administrator and the users who possesses appropriate attributes) can also view the log data at the bottom of this interface. As shown in Figure 17, the log data produced by the sensor includes dust, temperature, humidity, and atmospheric carbon dioxide.       Furthermore, the user can see detailed information stored in public block by clicking on the icon highlighted in Figure 16. As shown in Figure 18, along with all related information, the data input from private blockchain is available at the bottom of the content table of the public blockchain. Int. J. Mol. Sci. 2020, xx, 5 5 of 7 Figure 5. This is a figure.
Text Text

Formatting of Mathematical Components
This is an example of an equation: Please punctuate equations as regular text. Theorem-type environments (including propositions, lemmas, corollaries etc.) can be formatted as follows: Theorem 1. Example text of a theorem.
The text continues here. Proofs must be formatted as follows: Proof of Theorem 1. Text of the proof. Note that the phrase 'of Theorem 1' is optional if it is clear which theorem is being referred to.
The text continues here.

Conclusions
The logs produced by IoT devices contain important contents and private information, and can be used as evidences for digital forensic investigations. Our work has introduced an autonomous log storage management protocol with blockchain mechanism and access control for the IoT. Various security properties for the logs including robust identity verification, data integrity, non-repudiation, insider attack resistance, and the legality are achieved by the integration of blockchain and signature chain. Moreover, internal security issue has been addressed by fine-grained attribute-based access control. Security analysis demonstrates that our protocol satisfies various security requirements. Our work is well suited for the IoT with a good performance due to elliptic curve short key length, short BLS signature, efficient signcryption method, and multi-server architecture.
In this paper, we propose a protocol with general IoT applications. Domain applications (for instance, WBANs or smart electricity grids) with specific architectures will be considered for our future works with similar mechanisms. Autonomous model would be modified to other ones in which gateways or servers will perform the signscryption. Additionally, protocol performance should also be taken into account, which further improves communication efficiency of low-power devices in the IoT.