Blockchain-Enhanced Security for 5G Edge Computing in IoT

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The paper tackles an interesting area, but the proposed topic is already extensively studied and lacks sufficient novelty. Additionally, the security challenges described are rather general and not clearly justified. I’d suggest narrowing down your approach, clearly identifying specific, practical threats relevant to real-world 5G IoT or edge computing scenarios. It would also help to directly link your proposed solution to concrete protocols or architectures, making your contribution more focused and applicable in practice. This would enhance the originality and relevance of your paper.

Author Response

Please refer to the attached report.

Author Response File: Author Response.docx

Reviewer 2 Report

Comments and Suggestions for Authors

3.1.1: what is a synethetic authentication log? Is this essentially an aritifically generated log? If so, what sense does that entire section, including the diagram, even make?

3.1.2: What about feeding tampered data into the blockchain in the first place? immutability means that these faked datasets now become the "global truth" forever?

3.1.3: How can smart contracts mitigate the presented vulnerabilities? e.g. rate limiting works perfectly fine with centralized services for decades; how exactly is DDoS resilience enhanced by using a blockchain/smart contracts?

3.2.1: Not all permissionless blockchains do show high energy consumption; actually most blockchains disregarded the traditional "proof of work" idea for alternative approaches (bit Bitcoin though).
How do permissioned blockchains "balance security" better than permissionless ones?The author claims that traditional authentication approaches (OAuth, Kerberos) have limited scalability compared to blockchains - this highly doubtful unless concrete experimental results show proof of that. In tbl. 3, the author then contradicts himself regarding scalability.

Tbl. 3: There is a lot of misleading, in certain cases even false information in this table. Just to name a few occasions, aside from the scalability issue:
 - OAuth tokens can't be manipulated, they are, of course, cryptographically signed. 
 - That Kerberos tickets can be "spoofed im keys are compromised" is true but the statement itself doesn't imply anything useful by itself; if keys are compromised, blockchain-based authentication becomes moot too
 - Many consensus mechanisms do not require extensive computational overhead, esp. PoS.  Also PBFT doesn't produce computational overhead, it's just more intensive with regard to communication (a point on which the author, again, contradicts himself when looking at tbl. 12).
 - Real-time performance: It would be worth noting that there are also significant alternatives. Nobody would build a system like the proposed one using the Bitcoin blockchain, since it's not designed for that; but why then include it in a comparison table? There are other, even permissionless, blockchains which have avg. transactions times which can be <1 second, e.g. Solana.

3.3.1: How exactly did you provide this synthetic dataset? If it should correspond to a "realistic evaluation", what were your base assumptions and why did you chose the concrete parameters? Is the dataset public?

Tbl. 6: Gas fees, especially on Ethereum are prone to extreme volatility, which have led to single transaction fees in the 1000s (USD) in the past. Where do these numbers come from? How do they relate to proper longtime averages on Ethereum?
Tbl 7: Same questions, where do these numbers come from/on what basis did you chose them?

Fig. 2+3: I fail to recognize any meaning behind these figures. The dataset is synthetic, so what should these diagrams tell us?

-----
In conclusion:
- This paper overuses certain buzzwords. The author reiterates the same information over and over again in many different places without adding more/concrete information. A lot of information is fuzzy and inconcrete; they look like the author collected some ideas which have then been loosely connected, without any form of proper experimental results or reproducible work.
- The general idea of creating an artificial dataset on which all assumptions and evaluations are based upon is questionable with regard to conclusiveness. The lengthy proposal primarily focuses on this dataset, while almost everything else is only superficially mentioned. Also, where is the dataset? How does it look like?
- In several places, the author contradicts himself in the text. Some of them are outlined above, but I'm not going to list all of them here; frankly, this shouldn't happen at all and the goal of this review to provide a general evaluation of proposal quality, not to make finite lists
- Even though even the abstract references the AI-focused context of this proposal twice, there is hardly any hard information on how or even if AI may benefit the concept. There is no implementation, no concrete information how to integrate it or any experimental results. 
- Yes, there are layer-2 scaling solutions. The abstract would suggest that this concept has been properly integrated somewhere, but aside from a shallow comparison in sec. 4.2.3, there is nothing tangible.
- There is practically no implementation at all. Listing 1 is overly trivial, and not even this listing is discussed or properly put in context.

 

Author Response

Please refer to the attached report.

Author Response File: Author Response.docx

Reviewer 3 Report

Comments and Suggestions for Authors

The authors proposed a blockchain-based authentication framework to enhance security and resilience in 5G-enabled IoT applications. Generally, the paper is well structured and easy to follow. The obtained results seem interesting. However, the following comments should be addressed prior to any publications:
1)    Related work section should be largely improved: add more recent references along with a table at the end of the section to summarize the state of the art.
2)    In Figure 1, it is not clear how authentication logs are synthetically generated and how failure and success rates are determined.
3)    The author used different types of in-text citations, e.g. [] or Hewa et al. Please unify the reference style. Additionally, make sure the references are well cited in the text, for instance Hewa et al. in section 3.1.2 mises the reference.
4)    Regarding the blockchain side, the author did not give any information about the blockchain type used in the proposed framework? Is it private, public or hybrid? Additionally, did you use offline blockchain to store data or all data are sent online in the network?
5)    Please explain the technical aspect of blockchain network.
6)    Can you provide more specific details about the computational problems that were solved using Solidity !?
7)    Using blockchain in IoT is beneficial for security and privacy however it is computationally complex and not always suited for limited resources IoT devices. Please provide a complexity study of the proposed framework and show how it is suitable for real life IoT applications.
8)    In Table 5, I miss information about the used AI models (number of layers, how data are inputted/outputted, hyper-parameter tuning, etc.).
9)    Please give more details about how performance metrics are calculated (latency, success rate, etc.)
10)    A major weakness of the paper is that the author did not compared his work to the state of the art techniques. 

Author Response

Please refer to the attached report.

Author Response File: Author Response.docx

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

The authors have addressed the major issues I had with the previous version; however, regarding response 1: I can't find the claimed commitment in sec. 3.3 of the current version ("The dataset generation scripts and configuration parameters will be made publicly available upon publication to support reproducibility.”); also, it would probably a good idea, to directly provide a link in the paper.

response 2: how does this "pre-commit AI anomaly detection" work in practice?

 

Author Response

Please refer to the attached report.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

The authors addressed all my issues and concerns. I suggest the publication of the paper in the journal.

Author Response

We greatly appreciate the reviewer’s kind assessment and recommendation for publication. Thank you for your constructive input during the earlier review round, which helped improve the manuscript.