Next Article in Journal
Privacy-Preserving and Efficient Public Key Encryption with Keyword Search Based on CP-ABE in Cloud
Next Article in Special Issue
How Bad Are Bad Templates? Optimistic Design-Stage Side-Channel Security Evaluation and its Cost
Previous Article in Journal
Secure Boot for Reconfigurable Architectures
Previous Article in Special Issue
Hardware Performance Evaluation of Authenticated Encryption SAEAES with Threshold Implementation
 
 
Article
Peer-Review Record

Side-Channel Evaluation Methodology on Software

by Sylvain Guilley 1,2,*, Khaled Karray 1, Thomas Perianin 3, Ritu-Ranjan Shrivastwa 1,2,*, Youssef Souissi 1 and Sofiane Takarabt 1,2
Reviewer 1: Anonymous
Reviewer 2: Anonymous
Submission received: 2 August 2020 / Revised: 11 September 2020 / Accepted: 21 September 2020 / Published: 25 September 2020
(This article belongs to the Special Issue Side Channel and Fault Injection Attacks and Countermeasures)

Round 1

Reviewer 1 Report

The paper deals with evaluation methodology on software implementation in order to eliminate side-channel attacks. The paper is really great written, the methodology, the observations and main contribution is clear to the reader. I suggest to explain the abbreviations with the first use (for example DTW, CNN, CTC line num. 47 and 48). The main contribution is basically methodology for side-channel analysis on software implementations, showing how to detect and then repair leakage in an interative manner. Naturally, the goal is to have no leakage of the software implementation in front of horizontal and vertical attack. On the line number 151 GDM methodology is mentioned, it should be defined and explained (defined) earlier. The article contains mistakes that are related with Fig 2 and Fig 3. Figure 2 is really inappropriate, it is not in vector and the text is unreadable (it should be placed in Appendix on whole page that is rotated). Moreover, Fig 3 has the same label as Fig 2 and the Fig 3 is not referred in the text (It should be referred on line num. 203). It has to be corrected. In order to conclude the revision, the paper is interesting, the methodology, the observations and main contribution is clear. I have no more comments and I recommend to accept the article with minor revision.

Author Response

Comment: The paper deals with evaluation methodology on software implementation in order to eliminate side-channel attacks. The paper is really great written, the methodology, the observations and main contribution is clear to the reader.

 

  • Response: We thank the reviewer for the kind acknowledgement.
  • Revision details: N.A.

 

Comment: I suggest to explain the abbreviations with the first use (for example DTW, CNN, CTC line num. 47 and 48).

 

  • Response: We thank the reviewer for pointing out the correction. The suggested and other missed abbreviations, as well, are expanded in their first usage.
  • Revision details: Changes in lines 20, 21, 35, 37, 49, 51, 103, 156, 161, 179, 184, and 313 of the revised manuscript.

 

Comment: On the line number 151 GDM methodology is mentioned, it should be defined and explained (defined) earlier.

 

  • Response: We thank the reviewer for the comment. Additional sentence indicating the GDB methodology in the previous paragraph is added to address this issue.
  • Revision details: Changes in lines 162 and 165.

 

Comment: The article contains mistakes that are related with Fig 2 and Fig 3. Figure 2 is really inappropriate, it is not in vector and the text is unreadable (it should be placed in Appendix on whole page that is rotated).

 

  • Response: We thank the reviewer for pointing this out. Indeed, the figure should be in vector which was a mistake. The figure 2 is replaced with a vector image and rotated on a full page view within the text.
  • Revision details: The figure 2 is available on page 7 of the revised manuscript.

 

Comment: Moreover, Fig 3 has the same label as Fig 2 and the Fig 3 is not referred in the text (It should be referred on line num. 203).

 

  • Response: We thank the reviewer for pointing out the mistake. The captions for figures 2 and 3 are updated to provide more precision and figure 3 is also referenced in the updated article.
  • Revision details: The figures 2 and 3 are available on pages 7 and 8 respectively. Figure 3 is referred to in line number 199 of the revised manuscript.

Reviewer 2 Report

General

To the best of my knowledge this article tries to give an overview of side-channel leakage detection in cryptographic software implementations. I like the broad view the article gives on this topic and the viewpoint from of an evaluator. However, the article is difficult to read and there a lot of typos and grammatical errors in the article that should be fixed.


Horizontal leakage

The article states the contribution of a horizontal leakage detection and their repair but does not include any related work (e.g., [1,2,3]) in this field.

It is not clear to the reader whether the detected side-channel vulnerabilities in mbedTLS were found by the authors and their proposed methodology or are well-known and already fixed in a recent version of mbedTLS.

The article gives an idea how to fix the identified vulnerabilities (V1 to V6). However, fixing such vulnerabilities manually is error prone and needs to be done for every change in the software. Moreover, there are state-of-the-art algorithms that repair code automatically [1] which are not referenced.


Vertical leakage

Algorithm 1, which is presented as contribution, is a well-known approach to reduce to the number of samples in a trace, a so-called Points of Interest (PoI) selection.

In the abstract, the new methodology is described as "Vary the masks [...]; And subsequently vary the key" whereas in algorithm 1, first the key is varied and afterwards the mask to detect unmasked key leakage.


[1] Eliminating Timing Side-Channel Leaks using Program Repair
[2] SLEAK: A Side-channel Leakage Evaluator and Analysis Kit
[3] DATA - Differential Address Trace Analysis: Finding Address-based Side-Channels in Binaries

Author Response

Comment: The article is difficult to read and there a lot of typos and grammatical errors in the article that should be fixed

 

  • Response: We thank the reviewer for pointing out the error. The article has been proofread to fix all the typographical errors and gramatical mistakes. Some portions of text are also rephrased where required to make them more understandable.
  • Revision details: The changes can be found in lines 19, 98, 109, 124, 252, 306 and 345.

 

Comment: The article states the contribution of a horizontal leakage detection and their repair but does not include any related work (e.g., [1,2,3]) in this field.

 

  • Response: We thank the reviewer for pointing out the related works. All the suggested articles have been cited in the revised manuscript.
  • Revision details: The changes can be found on line number 18 and a new subsection has been added for the same “1.3. Related Works” (lines 76-93) in the revised manuscript.

 

Comment: It is not clear to the reader whether the detected side-channel vulnerabilities in mbedTLS were found by the authors and their proposed methodology or are well-known and already fixed in a recent version of mbedTLS.

 

  • Response: We thank the reviewer for pointing out the ambiguity. In order to efficiently address this, we introduce a new section.
  • Revision details: The new section “5. Discussion” can be found on page 12 (lines 334-341)

 

Comment: The article gives an idea how to fix the identified vulnerabilities (V1 to V6). However, fixing such vulnerabilities manually is error prone and needs to be done for every change in the software. Moreover, there are state-of-the-art algorithms that repair code automatically [1] which are not referenced.

 

  • Response: We thank the reviewer for the insightful remark. We address this point exclusively in the updated article with supporting text.
  • Revision details: The change addressing this comment can be found within the lines 77-82.

 

Comment: In the abstract, the new methodology is described as "Vary the masks [...]; And subsequently vary the key" whereas in algorithm 1, first the key is varied and afterwards the mask to detect unmasked key leakage.

 

  • Response: We thank the reviewer for finding out the discrepancy. We have addressed this comment by aligning the abstract text with the algorithm.
  • Revision details: The change can be found on lines 10, 11 and 12.

Round 2

Reviewer 2 Report

No further comments.

Back to TopTop