On the SCA Resistance of TMR-Protected Cryptographic Designs

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

1. In Section 2, the author reviews several existing approaches for conducting SCA attacks against TMR implementations. However, how does the proposed approach in this paper differ from these conventional methods?

2. What are the novel contributions or innovative perspectives introduced in this work? I think it is well-known that TMR can substantially influence side-channel leakage, 

3. Additional experimental validation would strengthen the study. 

4. Do other circuit design similarly affect the side-channel resistance of cryptographic implementations?

5. What are the comparative differences in side-channel leakage between TMR and other design?

Author Response

We thank the reviewer for the constructive feedback and insightful questions that have helped improve the clarity and impact of our work. Below, we provide detailed responses to each of the raised points.

 

Comments 1: In Section 2, the author reviews several existing approaches for conducting SCA attacks against TMR implementations. However, how does the proposed approach in this paper differ from these conventional methods?

Response 1:We appreciate this valuable question. First of all, we would like to clarify that in Section 2, we are not reviewing approaches for conducting SCA attacks against TMR implementations. Instead, we provide a state-of-the-art of the impact of TMR on the side-channel resistance of cryptographic implementations based on symmetric cryptographic algorithms. Unfortunately, no studies have been found that report such results for asymmetric approaches - this work is, to the best of our knowledge, the first one addressing this issue.

In response to the question, the applied evaluation method was not introduced in this paper; it is a widely accepted and conventional approach for assessing the SCA resistance of elliptic curve implementations. (please see Section 6.3.3.4 in Guidelines for Evaluating Side-Channel and Fault Attack Resistance of Elliptic Curve Implementations https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_46_ECCGuide_e_pdf.pdf?__blob=publicationFile&v=3)

 

Comments 2: What are the novel contributions or innovative perspectives introduced in this work? I think it is well-known that TMR can substantially influence side-channel leakage, 

Response 2: We agree that the general idea that redundancy affects side-channel leakage is recognized. However, the literature does not present a clear or consistent understanding of this effect. In some cases, applying TMR has been reported to enhance SCA resistance, while in others, it appears to increase vulnerability. In this work, we provide practical guidelines for selecting which blocks should be implemented with redundancy to improve side-channel resistance. To the best of our knowledge, this is the first experimental study evaluating fine-grained TMR application in an FPGA-based ECC accelerator, capturing real-world EM traces. Finally, our work provides practical design recommendations for balancing fault tolerance with SCA resistance, something that is often lacking in prior literature.

 

Comments 3: Additional experimental validation would strengthen the study. 

Response 3: Thank you for this important suggestion. We agree that further validation could enhance the strength of our findings. While the current study already includes 4 variants and measured EM traces on real hardware, we acknowledge the benefit of broader scope.

To address this, we have the following clarifying statement in the line 383 of the revised manuscript:

“In our future work we plan to investigate the impact of TMR on the success of at-tacks exploiting static currents, including those conducted under laser illumination or operating parameters variation.”

 

Comments 4: Do other circuit design similarly affect the side-channel resistance of cryptographic implementations?

Response 4: The structure, logic style, and resource allocation of various circuit designs can significantly impact side-channel leakage. In our paper, we show that even within the same cryptographic accelerator, applying TMR to different modules has opposite effects on resistance.

 

Comments 5: What are the comparative differences in side-channel leakage between TMR and other design?

Response 5: Our paper provides direct comparison between a baseline (non-TMR) design and four TMR variants. The key findings include:

- Full TMR (Design_4) does not significantly improve resistance compared to the original (Design_0).

- Selective TMR applied to the multiplier (Design_1) improves resistance by introducing noise.

- Selective TMR applied to key-dependent registers (Design_2) reduces resistance by amplifying key leakage.

- Combining TMR in both (Design_3) yields mixed results, showing that design granularity is critical.

These differences are summarized in Figure 8 and elaborated in Section 5.3.

 

Reviewer 2 Report

Comments and Suggestions for Authors

The article is interesting and sound. However, some points should be improved, in order to increase readability.

I believe that the crux of your research is how to delimit which modules ought to be replicated (TMR). Have you found out some clear criteria about this? It seems a "trial and error" process.

In line 354 you present TMR (more or less) like a "noise source". Is it worth leveraging TMR for this, instead of directly producing noise?

Is not there any gap between privacy (werable health care) and safety (space missions). I wonder whether attacks and resistance in both cases are (and must be) similar.

Could you explain wider "but also the signal propagation delays" in line 289?

Fig. 8 shows that candidates are orderly similar in each instance. Have you modulated their order, or they result similar in each step?

In line 202 you mention "i_ecc" for first time, but it doesn't appear until line 238 (or Fig. 3). Not in Fig. 2.

Fig. 3 is not easy to be read.

When you mention "scalar k" for first time in line 207, could it be suitable to add "(secret key)"?

(Minor point). Comma in "As target platform, authors used", line 94.

 

Author Response

We thank the reviewer for the constructive feedback and insightful questions that have helped improve the clarity and impact of our work. Below, we provide detailed responses to each of the raised points.

Comments 1: I believe that the crux of your research is how to delimit which modules ought to be replicated (TMR). Have you found out some clear criteria about this? It seems a "trial and error" process.

Response 1: You are absolutely right - identifying which modules should be replicated is central to our investigation. This was not a trial-and-error approach. Blocks that are always active but not dependent on the key (e.g., the field multiplier) act as inherent noise sources and are excellent candidates for triplication to mask leakage from other parts. Blocks that contribute significantly to key-dependent activity (e.g., registers accessed based on processed key bits) are sensitive to leakage and should be protected differently. These assumptions were confirmed by attacking Design_1 and Design_2 that represent respectively the best and the worst case from the designer’s point of view.

In general, such conclusions can be applied to any cryptographic design after identifying the blocks that contribute to side-channel leakage.

 

Comments 2: In line 354 you present TMR (more or less) like a "noise source". Is it worth leveraging TMR for this, instead of directly producing noise?

Response 2: This is an excellent question. We agree it is not always more efficient than targeted masking. Adding artificial noise is a common countermeasure in side-channel attack mitigation, but it has drawbacks. As in the case of TMR application, such a source of noise also requires additional resources, but more importantly, it has to be designed in such a way that the added noise cannot be filtered by an attacker. This part is not a trivial task. As for the multiplier, it acts as an inherent noise source. Additionally, implementing a multiplier using TMR leverages functional redundancy to provide fault tolerance. This dual-purpose use of resources can be particularly advantageous in industrial or critical applications, where both reliability and physical security are crucial.

 

Comments 3: Is not there any gap between privacy (werable health care) and safety (space missions). I wonder whether attacks and resistance in both cases are (and must be) similar.

Response 3: Thank you for this interesting comment. We agree that there are difference in the attack vectors, but there are also similarities. In both cases, and that holds true for all IoT based applications the integrity of the data that is measured and transmitted needs to be ensured. In addition in both application areas mentioned in this comment have high requirements with respect to reliability, i.e. both benefit from TMR and similar approaches. The major difference we see is the accessibility of the devices. This clearly differs significantly at least after deployment. But as development and manufacturing of cryptographic devices are challenging and costly we are convinced that application specific cryptographic designs are out of reach, i.e. cryptographic designs will be used in different application areas.

 

Comments 4: Could you explain wider "but also the signal propagation delays" in line 289?

Response 4: TMR introduces additional logic paths and voters, which can alter the timing of signal transitions. These changes in propagation delay affect the alignment and duration of switching activity captured in EM traces, thus influencing the shape and detectability of leakage in SCA.

We added the following text to line 290: “As TMR introduces additional logic paths and voters, it alters the timing of signal transitions. These changes in propagation delays affect the alignment and duration of switching activity, thus influencing the shape of captured EM traces and detectability of SCA leakage. ”

 

Comments 5: Fig. 8 shows that candidates are orderly similar in each instance. Have you modulated their order, or they result similar in each step?

Response 5: The candidates shown in Figure 8 correspond to fixed indices within the slot, i.e., each represents an attack guess for a specific clock cycle of a slot. The order is not modulated - it reflects the natural processing sequence of operations during execution.

 

Comments 6: In line 202 you mention "i_ecc" for first time, but it doesn't appear until line 238 (or Fig. 3). Not in Fig. 2.

Response 6: Thank you for catching this. We agree that the first reference to i_ecc may confuse the reader. We have revised the sentence at line 202 to delay its mention until its graphical context is introduced (line 211, before Figure 3).

 

Comments 7: Fig. 3 is not easy to be read.

Response 7: We acknowledge that the figure was not optimally formatted. We have increased the size of Figure 3 in the revised manuscript.

 

Comments 8: When you mention "scalar k" for first time in line 207, could it be suitable to add "(secret key)"?

Response 8: Thank you for this suggestion. We understand the intention to clarify that k is a sensitive value. However, we prefer not to label it as a “secret key” because this term is conventionally used in the context of symmetric cryptography. In our case, the scalar k refers to a secret ephemeral value used in elliptic curve computations, such as ECDSA or scalar multiplication. While leakage of k can indeed compromise the long-term private key, the scalar itself is not the private key. To maintain scientific accuracy and avoid confusion between symmetric and asymmetric key terminology, we have chosen to retain the original wording.

 

Comments 9: (Minor point). Comma in "As target platform, authors used", line 94.\

Response 9: Thank you. The comma has been added.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

I recommend that this paper be accepted after the authors make all experimental source data publicly available.

Author Response

Comments 1: I recommend that this paper be accepted after the authors make all experimental source data publicly available.

Response 1:We appreciate the reviewer’s suggestion and share the view that making experimental data publicly available is important for transparency and reproducibility. Unfortunately, in our case, this is not feasible.
The implementation includes cryptographic hardware modules that are classified as dual-use under German export control regulations. 
Due to the legal and regulatory restrictions, we are unable to publish the experimental source data. But we want to highlight that we can and will provide access to specific parts on individual request according to the rules of good scientific practice of the German Research Foundation

We thank the reviewer for their understanding.