A Cryptography-Powered Infrastructure to Ensure the Integrity of Robot Workflows

Round 1

Reviewer 1 Report

The authors became interested in a very important issue related to the protection (safety) of activities not only in the area of ​​programming (in the article an example of robot programming) but also in the management of automated and autonomous systems - which for some time has played a very important role in our private and professional life - it is the subject of many publications, conferences, is the subject of research by many centers, automation manufacturers, programmers, etc. - in other words, the security problem is present at every step!
For example, the security issue in Industry 4.0!?

In my opinion, the authors approached the problem in the most correct way, and the solutions obtained and the tests carried out confirm the effectiveness of the proposed solution.
Of course, We can ask: are the security solutions completely safe (ie 100%)?

The structure of the publication, summary, selection and analysis of literature, presentation of the research problem and it's solution, the tests carried out, as well as the summary and conclusions, I believe that the authors have done correctly, reliably and meticulously.
In conclusion, I recommend the publication.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

They authors present an interesting security issue, appearing at a certain part of the complete trip from design to consumption/implementation of robotic systems, that as they say, has been undermined in its significance.

I felt this work has a review feel to it, since it descibes the general aspects of an issue, which I found very appealing.

I believe it is very relevant to the journal and it should be considered for publication, after some minor issues are addressed. These are outlined below

--The firstname.lastname}@joanneum.at at the beginning, is it a typo?

--Line 42, " The basic idea is to seal the program after it has been accepted and prevent further intentional or unintentional modifications". I think at this point it is worth clarifying if this is done during execution, and if the control is impossed by the developer, user, or a regulatory body.

--Line 57, " Concerns for the integrity of the application come from accidental or intentional  modifications on the shop floor but also from a security-side". I would appreciate a second explanatory example here.

--Line 137, and it also appears elsewhere in the text. The authors mention 'we have' when refering to previous works. But some of these do not  include all of the authors of the current paper, only some of them. So it would be better to rephrase, as 'our research group', or something similar.

--Line 145, ' malicious actors', I think agents is more appropriate.

--Some figures, like Fig. 2 for example, can have coloured sub-parts (like different shades of blue) to underline the workflow better.

--Line 248, the client builds instead of 'she builds'

--Line 306, I think 'designated area' is more appropriate.

--Figure 7, the 20201112.pdf should be removed.

--Line 431 " the signature length does not depend on the workflow queue size". I found this somewhat confusing, since it affects the time (Fig 10). If I am not mistaken, the authors refer that the signature will have fixed length no matter how many subtasks or parameters one task has, but there will be many signing requests as per workflow length. 

Author Response

Please see the attachment

Author Response File: Author Response.pdf

Reviewer 3 Report

The proposed article is focused issue of the cryptography-powered distributed infrastructure for the preservation of robot workflows.

Main comments:

1. The introduction and related works is not sufficient and should definitely apply to a broader cross-section of contemporary works in this area.

2. I don't feel like the section "Accountability requirements" should exist as a separate chapter. Consider joining with another section.

3. The authors don't provide sufficient reasons for choosing Merkle tree. Why not Verkle Trees or others??

4. Authors should present strict bounds in the resulting estimates, significant for critical systems.

5. What is the applicability of the methods to these systems' unique needs: limited computational cost, the shape of the transmission delays distributions, etc.

6. The outline of the WorkflowManager API should be more detailed.

7. There is not sufficient information about the computational complexity of the whole solution.

Minor comments:
- It would be advisable to include the diagram of the proposed solutions/algorithms.

- Some figures are barely legible, i.e., Fig. 3, 9, 11.

- The work should be checked in terms of language.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf