A Traceable and Authenticated IoTs Trigger Event of Private Security Record Based on Blockchain

Round 1

Reviewer 1 Report

The paper studies how a blockchain can be used by a Security Control Company, to facilitate security services to individuals (in cases, e.g. of burglaries, thefts etc.). Several roles are expliticly defined (client, IoT Main Controller, Security Control Center, Security Guard, Blockchain Center), so as alarms generated by IoT devices within the home are appropriately processed.

 

The idea is interesting and the authors put much effort on providing explicit description of their idea. However, unfortunately the paper – in my opinion – has several important weaknesses, despite the authors’ obvious effort to cover any aspect. More precisely:

• Structural comments

 

I think that the authors do not explicitly define in their introduction which are the benefits of utilizing blockchain for this purpose. In my view, blockchain can be useful in such a context for establishing accountability – i.e. to store information in an immutable ledger, so as to allow checking at any later time what events and actions took place, without any doubt on their validity. This aspect is not highlighted in the paper – at least in the introduction (the reader needs to study the protocol in detail in order to “reveal” this feature).

 

On the contrary, other important design features of a blockchain are not being discussed at all. The authors refer to Ethereum and smart contracts, but this is not enough. For example, although the reader may assume that we obviously need a private (and not public) blockchain here, being permissioned, this feature is not discussed at all. Moreover, the consensus mechanism of the blockhain is also not discussed at all; for example, PoW is a main consensus mechanism in Ethereum but I assume that its usage in this context is prohibitable for efficiency reasons. Concluding, the authors do not provide any information of the necessary structural properties of the blockchain.

 

Last but not least, in my opinion privacy issues are not discussed at all and this raises several concerns. It is not fully clear who entity has access to the blockhain’s data, for what purpose, and how the security company ensures that users and guards’ privacy is not violated. For example, can any registered user see the whole blockchain, even if having access to specific blocks is not necessary? Is the information on the blockchain pseudonymised or not? Note also that unencrypted information on events (and relevant identifiers) seem to be stored in the blockchain (see, e.g., line 336), which raises major privacy (and security) concerns. In my opinion, a discussion on how privary risks can be mitigated must be included in such a paper.

 

• More specific comments

 

Dealing with the details of the protocol, several open questions arise. An indicative (but not complete) list is given next.

1. Page 6, line 206: “The SCC’s staff checks if it's a false alarm or not, and confirm it”. How does this checking take place? (this is also an issue in other parts of the paper).
2. Page 8, line 238: “When the connection is lost or hijacked by hackers, the SCC will automatically send a notification to SG to solve the communication problem”. First, if the session is hijacked, then this may not be known to the company (SCC). However, even if we assume that this phrase means “if the SCC identifies a session hijacking, then it will automatically send a notification to SG to solve the communication problem”, it is not clear how a security guard is able to solve such an issue.
3. Authentication phase (section 3.5, page 9): No parameter for the cryptographic signature scheme (ECDSA) is given (i.e. sizes of the public keys, hashed values etc.). I also think that the signature scheme in this paper is somehow an adaptation of the ECDSA and not exactly the same – so it would be better to clarify this and present the validity of the proposed signature scheme.
4. Page 9, line 272: The time T2 has not defined (I assume it is the time of reception of the message).
5. In several parts of the paper, a validity check of the timestamp is described (see, e.g., lines 272, 285, 310 etc.). Although I understand that the timestamp is utilized to prevent replay attacks, in my opinion this validity check is quite weak. First, it is not defined which is the acceptable delay threshold. Next, what if delay occurs due to network problems? Note also that an attacker could mount a DoS attack to cause delays in the transmission of the messages, thus affecting the proper behavior of the whole protocol. I would suggest that the authors consider other ways to deal with replay attacks, like other network security protocols do (e.g. through session id, sequential numbers etc.)
6. Lines 344-345: What happens if equation (40) does not hold?
7. Line 421: “If the client doubts the legality of a security event (…)”. What does it mean?

 

The English language should be also extensively checked throughout the paper.

 

Author Response

Reviewer 1 comments:

1. The paper studies how a blockchain can be used by a Security Control Company, to facilitate security services to individuals (in cases, e.g. of burglaries, thefts, etc.). Several roles are explicitly defined (client, IoT Main Controller, Security Control Center, Security Guard, Blockchain Center), so as alarms generated by IoT devices within the home are appropriately processed. The idea is interesting and the authors put much effort on providing explicit descriptions of their idea. However, unfortunately, the paper – in my opinion – has several important weaknesses, despite the authors’ obvious effort to cover any aspect.

Authors' response:

Thanks for the reviewer's interest in our idea. Regarding the reviewer’s opinion, our response in the following items.

 

2. I think that the authors do not explicitly define in their introduction which are the benefits of utilizing blockchain for this purpose. In my view, blockchain can be useful in such a context for establishing accountability – i.e. to store information in an immutable ledger, so as to allow checking at any later time what events and actions took place, without any doubt on their validity. This aspect is not highlighted in the paper – at least in the introduction (the reader needs to study the protocol in detail to “reveal” this feature).

Authors' response:

Thanks for the reviewer's valuable comment. In our paper, we mainly emphasize the traceable and verifiable characteristics of the blockchain. We have added some additional descriptions in lines 72-76 with red font.

 

3. On the contrary, other important design features of a blockchain are not being discussed at all. The authors refer to Ethereum and smart contracts, but this is not enough. For example, although the reader may assume that we obviously need a private (and not public) blockchain here, being permissioned, this feature is not discussed at all. Moreover, the consensus mechanism of the blockchain is also not discussed at all; for example, PoW is the main consensus mechanism in Ethereum but I assume that its usage in this context is prohibitable for efficiency reasons. Concluding, the authors do not provide any information of the necessary structural properties of the blockchain.

Authors' response:

Thanks for the reviewer’s reminder. We applied private blockchain with Proof of Authority (PoA) consensus mechanism in our scheme to protect the privacy of the client, the information of the client is confidential. The proposed scheme only allows authorized accounts to validate transactions and blocks. We have added some additional descriptions in lines 130-139 with red font

 

4. Last but not least, in my opinion, privacy issues are not discussed at all and this raises several concerns. It is not fully clear who entity has access to the blockchain's data, for what purpose, and how the security company ensures that user's and guards’ privacy is not violated. For example, can any registered user see the whole blockchain, even if having access to specific blocks is not necessary? Is the information on the blockchain pseudonymized or not? Note also that unencrypted information on events (and relevant identifiers) seem to be stored in the blockchain (see, e.g., line 336), which raises major privacy (and security) concerns. In my opinion, a discussion on how privacy risks can be mitigated must be included in such a paper.

Authors' response:

Only security service providers and arbitrators can access all blockchains, and then clients are only allowed to own their chains. The only information that will be disclosed during the transmission is the ID, and only the working staff that related to the client’s security event know the information that query by ID.

 

5. Page 6, line 206: “The SCC’s staff checks if it's a false alarm or not, and confirm it”. How does this check take place? (this is also an issue in other parts of the paper).

Authors' response:

Thanks for the reviewer’s comment. A description that how SCC checks if it’s a false alarm or not is added in lines 228-232 with red font, as follow: “The SCC’s staff will connect and check the recorded video from Digital Video Recorder(DVR) before and after the occurrence event time manually, every client’s house needs to install a digital video recorder (DVR) and connect it with multiple cameras to capture the critical area, those devices are classified in IoT devices. If there is no abnormal movement or object (e.g. human break-in, fire) in the video, then means it is a false alarm.”

 

6. Page 8, line 238: “When the connection is lost or hijacked by hackers, the SCC will automatically send a notification to SG to solve the communication problem”. First, if the session is hijacked, then this may not be known to the company (SCC). However, even if we assume that this phrase means “if the SCC identifies a session hijacking, then it will automatically send a notification to SG to solve the communication problem”, it is not clear how a security guard is able to solve such an issue.

Authors' response:

Thanks for the reviewer’s suggestion. Being hacked will cause communication loss. To simplify the IoT main controller being hacked, we classify it as a disconnected state. So we delete the original descriptions in line 265.

 

7. Authentication phase (section 3.5, page 9): No parameter for the cryptographic signature scheme (ECDSA) is given (i.e. sizes of the public keys, hashed values, etc.). I also think that the signature scheme in this paper is somehow an adaptation of the ECDSA and not exactly the same – so it would be better to clarify this and present the validity of the proposed signature scheme.

Authors' response:

Thanks for the reviewer’s suggestion. We supplement the description of relevant parameters for ECDSA from lines 153-155 with red font. As the reviewer said, this study applied ECDSA-like signatures to implement our system, which is essentially evolved from ECDSA.

 

8. Page 9, line 272: The time T2 has not been defined (I assume it is the time of reception of the message).

Authors' response:

Thanks for the reviewer’s suggestion. We have defined T_i and T_i+1 as the timestamp from the sender and the timestamp received by the receiver respectively. The notation is modified in section 3.2 with red font.

 

9. In several parts of the paper, a validity check of the timestamp is described (see, e.g., lines 272, 285, 310, etc.). Although I understand that the timestamp is utilized to prevent replay attacks, in my opinion, this validity check is quite weak. First, it is not defined which is the acceptable delay threshold. Next, what if a delay occurs due to network problems? Note also that an attacker could mount a DoS attack to cause delays in the transmission of the messages, thus affecting the proper behavior of the whole protocol. I would suggest that the authors consider other ways to deal with replay attacks, like other network security protocols do (e.g. through session id, sequential numbers, etc.)

Authors' response:

Thanks for the reviewer’s suggestion. As the reviewer reminder, The notation of sequential numbers has been added in section 3.2. In a round of the phase executed, the sequential number added in every message from the sender. The analysis of the replay attack added in lines 608-611.

 

10. Lines 344-345: What happens if equation (40) does not hold?

Authors' response:

When equation (40) does not hold, it indicates that the message has been falsified, the sender will not receive the reply message from the receiver in time, the sender will need to retry sending the same message within a valid number of attempts.

 

11. Line 421: “If the client doubts the legality of a security event (…)”. What does it mean?

Authors' response:

It means that when any client has doubts about a security event processing process, the client able to appeal to a third party (Official Agency) to verify the legality of the process.

 

12. The English language should be also extensively checked throughout the paper.

Authors' response:

Thanks for the reviewer’s suggestion. The typos and grammar in the paper have been rechecked and revised repeatedly.

 

Author Response File: Author Response.docx

Reviewer 2 Report

In this manuscript, they proposed a mechanism to make security event records have the authenticated, traceable, and integral characteristics. The manuscript is written well. However, there are two suggestions to improve the quality of the manuscript. 

 

1) They should emphasize the proposed method focused on traceable and authenticated with compared previous works. It seems to be first proposed to achieve security event records having the authenticated, traceable, and integral characteristics. Also, it should be described not only Usefulness(i.e., Traceable or Authenticated), but also its usability(i.e., Why was the proposed method designed that way?).

 

2) They assumed that the communication environments were ideal and calculated with message size. To consider the reliable environment,  they should add another environment(i.e., with the environment as shown in Figure 1). 

Author Response

Reviewer 2 comments:

1. In this manuscript, they proposed a mechanism to make security event records have the authenticated, traceable, and integral characteristics. The manuscript is written well. However, there are two suggestions to improve the quality of the manuscript.

Authors' response:

Thanks for the reviewer’s suggestion and positive comments. We have replied reviewer’s suggestion in the next two items, we have also modified the article with red font.

 

2. They should emphasize the proposed method focused on traceable and authenticated with compared previous works. It seems to be first proposed to achieve security event records having the authenticated, traceable, and integral characteristics. Also, it should be described not only Usefulness(i.e., Traceable or Authenticated), but also its usability(i.e., Why was the proposed method designed that way?).

Authors' response:

Thanks for the reviewer’s suggestion. In Line 65-76, we describe the characteristics of Blockchain and using the technology to achieve the goals in lines 77-80. The traditional security system has certain shortcomings, we describe the weakness of a traditional security system in lines 56-64. Therefore, we have integrated Blockchain technology to achieve usability, making our services more secure.

 

3. They assumed that the communication environments were ideal and calculated with message size. To consider the reliable environment, they should add another environment(i.e., with the environment as shown in Figure 1).

Authors' response:

Thanks for the reviewer’s suggestion. As we described in Subsection 1.1, the environment to be monitored by security services including fire, theft, burglary, and other such dangers. Those types of security monitoring can be detected by IoT devices, just like what we showed in figure 1. Figure 1 shows our main system environment, we use IoT technology to detect the incident event, e.g. fire or thief. Other detections like toxic gas detection can also be added, just only need to add more sensors to increase the type of detection. The main environment showed in Figure 1, we also consider another scenario in Figure 2, when the IoT devices or main controllers in the client’s house are disconnected, the security control center’s staff also able to check and allocate security guards go to the incident scene to solve the problem. If the reviewer still has any concerns, please give us more advice, we appreciate any comments.

Author Response File: Author Response.docx

Reviewer 3 Report

This is a strong overall paper describing methods to secure IoTs with blockchain. The authors are providing ample details, and references describing their suggested implementation, however some important pieces are missing.

The use of blockchains is only one aspect of the security securing such a scheme, the other aspect is the use of public-private key pairs, with digital signatures (DSA). The authors are doing an excellent job to explain how to use elliptic curves ECDSA to provide integrity, non-repudiation, and protection against attacks such MIM, Replay and others. However, they should also worry about the attacks targeting the integrity of the key pairs during distribution, storage, and use of these keys. Attacks such as side channel attacks are known to "steal" the keys during signature cycles. A loss to the opponent of the key pairs would simply destroy the entire security scheme proposed by the authors. So I recommend the following:

 >lines 65-66. Nakamoto did not "invent" Blockchains", he proposed a very well though scheme using blockchain and DSA to protect crypto-currencies. 

>lines 165-166. The authors should mention the importance of the integrity of the key-pairs, and the risk associated with the distribution, storage, and use of these keys. References describing side channel attacks, and DPA are needed.

> Section 3-1. The authors should develop ways to distribute store and use the key pairs. It is my understanding that each client has only one key pair, but one key-pair per IoT could also work.

> line 222. The role of the token is interesting, and should be further developed. The authors are mentioning that the tokens are important to confirm the "identity" of the clients. It is also possible to use tokens providing "authentication" with secret keys. This could greatly enhance the overall security scheme.

> Section 4; The authors should include attacks, and suggested remedies against loss of the key pairs

 

In summary, this is excellent work, the authors should include some of these recommendations to make it stronger.

Author Response

Reviewer 3 comments:

1. This is a strong overall paper describing methods to secure IoTs with blockchain. The authors are providing ample details, and references describing their suggested implementation, however, some important pieces are missing.

The use of blockchains is only one aspect of the security securing such a scheme, the other aspect is the use of public-private key pairs, with digital signatures (DSA). The authors are doing an excellent job to explain how to use elliptic curves ECDSA to provide integrity, non-repudiation, and protection against attacks such MIM, Replay, and others. However, they should also worry about the attacks targeting the integrity of the key pairs during distribution, storage, and use of these keys. Attacks such as side-channel attacks are known to "steal" the keys during signature cycles. A loss to the opponent of the key pairs would simply destroy the entire security scheme proposed by the authors. So I recommend the following.

Authors' response:

Thanks for the reviewer’s suggestion. Regarding the reviewer’s recommendation, our response in the following items, we have also modified the article with red font.

 

2. lines 65-66. Nakamoto did not "invent" Blockchains", he proposed a very well thought scheme using blockchain and DSA to protect crypto-currencies.

Authors' response:

Thanks for the reviewer’s reminder, we have modified the description in lines 65-66.

 

3. lines 165-166. The authors should mention the importance of the integrity of the key-pairs, and the risk associated with the distribution, storage, and use of these keys. References describing side-channel attacks, and DPA are needed.

Authors' response:

Thanks for the reviewer’s suggestion. The description of side-channel attacks has been added in lines 187-191 and lines 620-627.

 

4. Section 3-1. The authors should develop ways to distribute store and use the key pairs. It is my understanding that each client has only one key pair, but one key-pair per could IoT also work.

Authors' response:

Thanks for the reviewer’s suggestion. As the reviewer said, we have already mentioned that each client has one key pair in lines 218-223, the IoT main controller and IoT will also need to register to BCC to get the ID, public key, and private key pairs and map the information to client’s smart contract structure. The distribution and storage of the keys are modified the same as the previous point.

 

5. line 222. The role of the token is interesting, and should be further developed. The authors are mentioning that the tokens are important to confirm the "identity" of the clients. It is also possible to use tokens providing "authentication" with secret keys. This could greatly enhance the overall security scheme.

Authors' response:

Thanks for the reviewer affirming the proposed scheme. In lines 292-293, we described that the secret key (we use the terms in private key) should be added with the signatures in Equations 4 and 5, then those equations should be verified in equation 9.

 

6. Section 4; The authors should include attacks, and suggested remedies against loss of the key pairs

Authors' response:

Thanks for the reviewer’s suggestion. The phase of key recovery against loss of the key pairs is added in section 3.10 with red font. If any accessing party noticed that the key pairs are stolen by attackers, the staff in the security company will need to notify the user to recover his/her key.

 

7. In summary, this is excellent work, the authors should include some of these recommendations to make it stronger.

Authors' response:

Thanks for the reviewer’s recommendation. Please tell us more, if the reviewer still has any questions after the modification.

Author Response File: Author Response.docx

Round 2

Reviewer 1 Report

The revised version of the paper provides some more details on several issues that had been identified in the first review round and, this, it is indeed a much better paper.

However, in my opinion, there are still several issues.

First, the authors imply that actually each client of the company will have its own blockchain; looking at the authors response to the reviews comments, they state, in point 4, "Only security service providers and arbitrators can access all blockchains, and then clients are only allowed to own their chains". I am very reluctant if this a realistic scenario (a separate blockchain for each client). If the only solution for addressing privacy issues is to devote a different blockchain to each client, then maybe a blockchain is actually not the right solution. The authors could possibly rely on privacy preserving technologies in blockchains to address this issue (e.g. via the channel concept being present in the Hyperledger Fabric) but they did not mention it in the paper.

 

Moreover, their overall model is based on the assumption that, in order to identify false positive alarms, the whole house should be monitored, in real time, by CCTV (see lines 228-233 in the revised paper). Although I understand that this is something that could be negotiated in the contract between the client and the security company, it seems strange to utilize such a CCTV always (are the clients willing to accept it?); and, if yes, then why we need all the other information from the sensors if the video suffices to provide any information on possible safety events?

 

I would also like to have a more clear presentation on the modified ECDSA algorithm, in order to clarify its security properties. The validity of this modified scheme, as asked in the first review round (see point 7) seem to still be missing...

Regarding the point 6 from the first review report, the authors state ".Being hacked will cause communication loss". So, they actually consider only DoS attacks in this scenario. But what about, e.g, MitM attacks? (do the authors imply that the adopted encryption does not use any other measure?)

Although this paper may provide a framework for deriving a nice solution for the problem discussed, in my opinion it is not a full solution yet, due to several issues - like those presented above. It should be also noted that, regarding the performance, there should be a reference in the performance of the blockchain (i.e. the consensus mechanism by itself), since it seems that it is essential to achieve high speed in writing into the blockchain.

 

On the basis of the above comments, I am unfortunately more towards rejection. In my opinion, the paper could be possibly published if it explicitly stated that this is a framework that need to be further elaborated and not a concrete full solution yet; the benefits of using blockchains need to be further justified in any case.

 

 

 

 

 

Author Response

Reviewer 1 comments:

1. The revised version of the paper provides some more details on several issues that had been identified in the first review round and, this, it is indeed a much better paper.

However, in my opinion, there are still several issues.

First, the authors imply that actually, each client of the company will have its own blockchain; looking at the authors' response to the reviews comments, they state, in point 4, "Only security service providers and arbitrators can access all blockchains, and then clients are only allowed to own their chains". I am very reluctant if this a realistic scenario (a separate blockchain for each client). If the only solution for addressing privacy issues is to devote a different blockchain to each client, then maybe a blockchain is actually not the right solution. The authors could possibly rely on privacy-preserving technologies in blockchains to address this issue (e.g. via the channel concept being present in the Hyperledger Fabric) but they did not mention it in the paper.

Authors' response:

Thanks for the reviewer’s comments. We replied to our comments that this is a private chain, only authorized persons are eligible to access the blockchain. But since the blockchain is a decentralized system, it still needs to have control rights for enterprise applications. In commercial applications, there are also lots of private and permission blockchains based on the Ethereum framework that can be implemented, for example,

• Quorum(https://github.com/ConsenSys/quorum)
• HydraChain(https://github.com/HydraChain/hydrachain)

So, based on the privacy or security issue, the current blockchain technology still has many applications.

2. Moreover, their overall model is based on the assumption that to identify false positive alarms, the whole house should be monitored, in real-time, by CCTV (see lines 228-233 in the revised paper). Although I understand that this is something that could be negotiated in the contract between the client and the security company, it seems strange to utilize such a CCTV always (are the clients willing to accept it?); and, if yes, then why we need all the other information from the sensors if the video suffices to provide any information on possible safety events?

Authors' response:

The camera only needs to be set under the eaves or above the door. As long as the security company communicates with the client and convinces them of the benefits, most of the clients will accept it. Besides, we believe that CCTV monitoring can also be set up indoors to shoot specific important objects (such as security boxes, expensive paintings, etc.) to monitor, and multiple mechanisms are used to ensure the safety of high-value objects. The event triggering will still be based on sensors, and the CCTV is only an auxiliary device for video monitoring. Therefore, The security company only needs to turn on the CCTV of the customer's house to monitor, when receiving the event trigger message.

 

3. I would also like to have a more clear presentation on the modified ECDSA algorithm, in order to clarify its security properties. The validity of this modified scheme, as asked in the first review round (see point 7) seems to still be missing...

Authors' response:

Thanks for the reviewer’s comment. Our paper focuses on the application of security services. The prove of the ECDSA algorithm is not our main focus issue. For more details of ECDSA can refer to the reference “The Elliptic Curve Digital Signature Algorithm (ECDSA)” proposed by Johnson et al. (https://doi.org/10.1007/s102070100002).

 

4. Regarding point 6 from the first review report, the authors' state ".Being hacked will cause communication loss". So, they consider only DoS attacks in this scenario. But what about, e.g, MitM attacks? (do the authors imply that the adopted encryption does not use any other measure?)

Authors' response:

Thanks for the reviewer’s suggestion. About the Man-in-the-Middle attacks, we have added a clearer description and made some corrections with a red font in Lines 598 to 614.

 

5. Although this paper may provide a framework for deriving a nice solution for the problem discussed, in my opinion, it is not a full solution yet, due to several issues - like those presented above. It should be also noted that, regarding the performance, there should be a reference in the performance of the blockchain (i.e. the consensus mechanism by itself), since it seems that it is essential to achieve high speed in writing into the blockchain.

Authors' response:

Thanks for the reviewer’s opinion. As the reviewer’s comments, there is indeed a performance problem. This is the shortcoming of the blockchain. In these recent years, Ethereum and Hyperledger have made efforts to the issues, the update has been published recently, such as Ethereum 2.0, Hyperledger Besu, Azure Blockchain Service, etc. that able to apply in the enterprise application. This is a trend of blockchain in the future to solve the problems questioned by the reviewer. We are very grateful for the valuable comments of the reviewer, and we will treat the comment as our future research.

 

6. On the basis of the above comments, I am unfortunately more towards rejection. In my opinion, the paper could be possibly published if it explicitly stated that this is a framework that needs to be further elaborated and not a concrete full solution yet; the benefits of using blockchains need to be further justified in any case.

Authors' response:

Thanks for the reviewer’s valuable comments. Based on the above replies, our research focuses on what problem to solve and the framework. We will refer to these comments and implement them for future works, thanks!

Author Response File: Author Response.docx

Reviewer 2 Report

To this revised manuscript, my decision is "accepted". 

Author Response

Reviewer 2 comments:

To this revised manuscript, my decision is "accepted". 

Authors' response:

Thanks for approving and accepting our research.

Reviewer 3 Report

The revised version is acceptable as is.

Author Response

Reviewer 2 comments:

To this revised manuscript, my decision is "accepted". 

Authors' response:

Thanks for approving and accepting our research.

Round 3

Reviewer 1 Report

The paper could be published in its present form, since it constitutes a basis for further exploring/investigating this idea.

With regard to my previous review report, and especially the comment on the mofidied ECDSA, it should be pointed out that of course I didn't suggest the authors prove the security on ECDSA; I suggested the authors show that their modified version of ECDSA provides the same security guarantees (without necessarily a formal proof) as the original ECDSA. In any case, under the assumption that this work provides a well-determined framework for further inverstigation, this could be the aim of future work.

Please also correct a typing error in line 601 (Man-in-the-middle instead of Main-in-the-middle).

 

Author Response

Reviewer 1 comments:

1. The revised version of the paper provides some more details on several issues that had been identified in the first review round and, this, it is indeed a much better paper.

However, in my opinion, there are still several issues.

With regard to my previous review report, and especially the comment on the modified ECDSA, it should be pointed out that of course, I didn't suggest the authors prove the security on ECDSA; I suggested the authors show that their modified version of ECDSA provides the same security guarantees (without necessarily a formal proof) as the original ECDSA. In any case, under the assumption that this work provides a well-determined framework for further investigation, this could be the aim of future work.

Authors' response:

Thanks for the reviewer’s suggestion. We add more explanations about ECDSA in lines 153 to 166, and a description in lines 653 to 662 with red font.

(1)Lines 153 to 166:

Next, we briefly describe the 3 phases of ECDSA key generation for verification:

• Key generation phase: We assume that any participant must apply to our blockchain center for public and private keys, the key generation with ECDSA as follows: , where is the participant ID,  is the public key,  is the private key,  is a generating point based on the elliptic curve. The public key  and private key  send to the participant and store.  also will be stored in the blockchain center.
• Signature phase: There is a message need to be sent by participant X to X choose a random number k between 1 and n-1, calculates a point on the curve as follows . Then calculates . Next, X sign a message M as follows: , sends to Y
• Verification phase:

When Y receives , then calculate parameters as follows: . Then verify  to determine if the signature is valid.

 

(2) Lines 653 to 662:

“We have implemented and modified the ECDSA, the verification of ECDSA can be verified by using the method introduced in Section 2.2. Based on the security of the Elliptic Curve Digital Signature Algorithm (ECDSA) is the discrete logarithm problem. The ECDSA for the details of the proof refers to section 8.1 of Ref. [29].

Besides, we also give two examples of the verification is derived for checking the hash value show as follows:

• In the authentication phase, the verification is verified as follows:
• In the event-trigger phase, the verification is derived as follows:

 

2. Please also correct a typing error in line 601 (Man-in-the-middle instead of Main-in-the-middle).

Authors' response:

Thanks for the reviewer’s reminder, we have corrected the error in the article as follows. “Man-in-the-middle attack”

Author Response File: Author Response.docx