ChronoEOS 2.0: Device Fingerprinting and EOSIO Blockchain Technology for On-Running Forensic Analysis in an IoT Environment^†

Round 1

Reviewer 1 Report

Summary:  The authors created an updated/improved version of the ChronoEOS system (ChronoEOS 2.0) which is capable of concretely recording the actions made by multiple industrial robots to an EOSIO blockchain, which inevitably aids in forensic investigations after the fact. ChronoEOS 2.0 operates by considering the private key of an administrative account and the SHA-256 fingerprint of the robot in question to record events to the blockchain such that security and non-repudiation are assured. The authors also evaluated the ChronoEOS 2.0 system based on resource consumption (CPU, RAM, and network packet transmission) and compared this system’s performance with that of the original ChronoEOS system. Most notably, ChronoEOS 2.0 suffers from about double the CPU usage as its predecessor and experiences disparate readings in terms of the amount of received data.

Though the proposed system is theoretically sound, I take pause regarding the claims that it provides "guaranteed security and reliability".

 

Recommendations:

Line 293: Should this read “ChronoEOS 2.0 consists of the following…” and Not “ChronoEOS consists of the following…”?

Why calculate the device fingerprint every time there is an updated event? Why not calculate the fingerprint once, and monitor the IP address so you only recalculate the fingerprint whenever the IP changes? Wouldn’t this reduce CPU usage?

How do you protect the administrator’s private key from compromise? Where/how is this key stored?

 

Have you considered the privacy/security and potential for compromise of the system and the private key: Network spoofing? Man-in-the-middle? An attacker can brute force the fingerprint (technically): if the robot models are the same, which means the only variable to consider is the IP address. Maybe the attacker has access to the network and is able to determine the IP address of the target robot; What happens then? The Device Fingerprinting module may be compromised, the immutability and reliability of the blockchain may be compromised, and thus so too the forensic analysis results. I think the paper will benefit from including a small section/paragraph discussing the forensic implications of compromise of the system.

Author Response

Dear Reviewer,

My co-authors and I would like to re-submit the revised manuscript titled "ChronoEOS 2.0: Device Fingerprinting and EOSIO blockchain technology for on-running forensic analysis in an IoT environment" to Smart Cities. First of all, we would like to thank you for your corrections and suggestions. Those presented corrections and recommendations have allowed us to develop an improved investigation and, therefore, a better scientific article. According to your observations, the paper has been carefully revised and modified:  

1. Line 293: Should this read “ChronoEOS 2.0 consists of the following…” and Not “ChronoEOS consists of the following…”?

Thank you for noticing, corrected.

2. Why calculate the device fingerprint every time there is an updated event? Why not calculate the fingerprint once, and monitor the IP address so you only recalculate the fingerprint whenever the IP changes? Wouldn’t this reduce CPU usage?

Thank you very much for the suggestion. The truth is that we had not considered that option, and surely the CPU usage will be reduced. However, we believe that calculating the fingerprint once and monitoring the IP would be less secure than calculating it every time you want to add a new event in the blockchain. This is because with current IP masking techniques, a possible point of attack could be to impersonate that device only by knowing the device's IP. Thus, if you know the user's IP and private key and make a request to ChronoEOS to add a new event, ChronoEOS would not check your fingerprint to ensure that the call is being made from the previously registered device. The second security factor would be eliminated in this case. 

3. How do you protect the administrator’s private key from compromise? Where/how is this key stored?

Logically, in any blockchain environment, the management of the private key by each user is an essential aspect of security, since this private key is the one that allows the user to perform all transactions.

In ChronoEOS 2.0 there is a general administrator, who is the one that deploys the Smart Contract in the first place, but there are also other accounts (one for each Lookout Agent, or robot), which have permissions to execute the functions of that contract and are the ones that make the calls when a new event is detected in the corresponding robot.

In short, each LookOut Agent has its own private key and they are the ones who call the Smart Contract, not the administrator.

4. Have you considered the privacy/security and potential for compromise of the system and the private key: Network spoofing? Man-in-the-middle? An attacker can brute force the fingerprint (technically): if the robot models are the same, which means the only variable to consider is the IP address. Maybe the attacker has access to the network and is able to determine the IP address of the target robot; What happens then? The Device Fingerprinting module may be compromised, the immutability and reliability of the blockchain may be compromised, and thus so too the forensic analysis results. I think the paper will benefit from including a small section/paragraph discussing the forensic implications of compromise of the system.

Thank you very much for the observation. We have in mind the complications that you rightly mentioned.

When the Lookout Agent makes a call to the Smart Contract, it does so via a REST API, in which it must add in the body of the call its own private key. If this call is intercepted somehow, the attacker could know the private key and, therefore, as you rightly comment, the system's security is compromised since one of the two security barriers of the system is broken. However, it would remain to overcome Device Fingerprinting.

As we have this problem in mind and to expose it clearly in the proposed work, we have added a paragraph in the "Discussion" section explaining a possible future line to secure further the API calls. A security solution would be employing an Identity Provider to control the access permissions to that API through some authorization protocol, such as OAuth2. In this way, in the header of the call, the authorization token (which expires after a certain time) would have to be included to execute the API call. Another option could be to make the fingerprint variable. That is, the parameters with which the robot's fingerprint is calculated could be changed each time an event is registered. Thus, if an attacker manages to discover the robot's IP, private key, and fingerprint, this would only be useful for a certain period of time. However, both methods would be slower since the authorization token or the fingerprint would have to be renewed every so often.

As you point out, the only variable that differentiates two equal robots is their IP address since the rest depends on the robot's physical characteristics. However, supposing that the attacker has intercepted a call, knowing the IP of the LoooutAgent, they needs access to the network. That access is needed due to the adversary does not know the necessary configuration variables and the algorithm used to compute the fingerprint.

The following lines are added to the paper in the Discussion section: "Compared to the previous version of ChronoEOS, the improvement in terms of application security is clear, as the Device Fingerprinting module adds an extra layer of security that is difficult for a potential attacker to overcome. On the other hand, regarding the results obtained, in relation to the consumption of system resources, it is observed that the results are similar to those obtained with the previous version. Thus, it is shown that the application is lightweight, which is a very important aspect in industrial environments. This is so because if the application is to be deployed in the same robot software, it is necessary that it interferes minimally in the performance of the robot, i.e., not to occupy system resources (which are usually limited) that the robot may need to perform its tasks. As an aspect to be improved to make the tool more reliable and with better performance, it is desirable to improve the security of the blockchain itself. In other words, the EOSIO blockchain must be protected so that it does not suffer unexpected crashes or attacks that could compromise the persistence of the data recorded there. For this reason, it is proposed for future versions to choose another blockchain technology with greater intrinsic security, since this is the most important aspect when choosing one type of blockchain or another. Aspects such as the speed of transactions is not particularly critical in forensic analysis tasks. Another important problem to be solved in the near future is the management of the private key of the users with permissions to use the application, i.e. those for whom the Smart Contract has been deployed on the blockchain. The private key is an essential parameter in the security of the system, since it is one of the two methods to ensure that ChronoEOS is not being used fraudulently, together with the Device Fingerprinting module." 

We thank you for re-considering our manuscript and hope that it is now acceptable for publication in Smart Cities.

Sincerely,

Alvaro Fernandez, Xabier Echeberria, Francesco Zola, Daniel Paredes, Raul Orduna

Reviewer 2 Report

This article aims to present ChronoEOS2.0, a solution based on blockchain technology and device fingerprinting that allows having a record of evidence of the events that occur in an industrial environment. The article has an interesting approach, however there are some issues to be revised:

 1. There is an unnecessary period at the end of the article title.

2. The Discussion section could more clearly present the positive and negative points of the presented solution when compared to the previous one and other existing ones.

Author Response

Dear Reviewer,

My co-authors and I would like to re-submit the revised manuscript titled "ChronoEOS 2.0: Device Fingerprinting and EOSIO blockchain technology for on-running forensic analysis in an IoT environment" to Smart Cities. First of all, we would like to thank you for your corrections and suggestions. Those presented corrections and recommendations have allowed us to develop an improved investigation and, therefore, a better scientific article. According to your observations, the paper has been carefully revised and modified:  

1. There is an unnecessary period at the end of the article title.

Thank you for noticing, corrected.

2. The Discussion section could more clearly present the positive and negative points of the presented solution when compared to the previous one and other existing ones.

The "Discussion" section has been improved, adding the advantages and disadvantages of the solution, in a more detailed way. We have also added a paragraph expressing the existing weakness in the management of the private key and proposing as a future solution to add an identity manager (IdP). The following lines are added to the paper, in Discussion section:

"Compared to the previous version of ChronoEOS, the improvement in terms of application security is clear, as the Device Fingerprinting module adds an extra layer of security that is difficult for a potential attacker to overcome.

On the other hand, regarding the results obtained, in relation to the consumption of system resources, it is observed that the results are similar to those obtained with the previous version. Thus, it is shown that the application is lightweight, which is a very important aspect in industrial environments. This is so because if the application is to be deployed in the same robot software, it is necessary that it interferes minimally in the performance of the robot, i.e., not to occupy system resources (which are usually limited) that the robot may need to perform its tasks.

As an aspect to be improved to make the tool more reliable and with better performance, it is desirable to improve the security of the blockchain itself. In other words, the EOSIO blockchain must be protected so that it does not suffer unexpected crashes or attacks that could compromise the persistence of the data recorded there. For this reason, it is proposed for future versions to choose another blockchain technology with greater intrinsic security, since this is the most important aspect when choosing one type of blockchain or another. Aspects such as the speed of transactions is not particularly critical in forensic analysis tasks.

Another important problem to be solved in the near future is the management of the private key of the users with permissions to use the application, i.e. those for whom the Smart Contract has been deployed on the blockchain. The private key is an essential parameter in the security of the system, since it is one of the two methods to ensure that ChronoEOS is not being used fraudulently, together with the Device Fingerprinting module."

 

We thank you for re-considering our manuscript and hope that it is now acceptable for publication in Smart Cities.

Sincerely,

Alvaro Fernandez, Xabier Echeberria, Francesco Zola, Daniel Paredes, Raul Orduna

 

 

Round 2

Reviewer 1 Report

The authors mostly addressed the recommendations where necessary;  However, are few things need to be fixed:

Line 292: Missing citation: "Fernández et al. in [? ],..."

Line 293: Authors did not address this comment in the paper: Should this read “ChronoEOS 2.0 consists of the following…” and Not “ChronoEOS consists of the following…”?

Author Response

Dear Reviewer,

First of all, thank you very much for accepting the corrections made to the paper and for contributing with your comments to improve the final version of the paper.

We have already fixed the two minor problems you mentioned. In line 293 we have added "ChronoEOS 2.0" and the reference in line 292 should now look correct.

Thank you very much again.