Stability-Aware Security–Performance Trade-Off Analysis in Resource-Constrained IoT Systems: A Time-Series and Bootstrap-Based Evaluation of TLS and Hybrid ECC–AES Mechanisms

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

• The presented work presented a stability-aware and statistically robust evaluation of security–performance trade-offs in resource-constrained IoT systems.
• The obtained results had been done through controlled experimentation on ESP32-based nodes, three communication configurations—unencrypted MQTT, MQTT over TLS 1.2, and a hybrid application-layer ECC–AES scheme—were compared across energy consumption, latency, and memory utilization. 
• The obtained results did not compared to other references such as:

1. S. K. Chakravarty, A. Batra, N. Singh and G. Kumar, "The Effect of TLS Encryption on MQTT Protocol Security and Performance in Meteorological-IoT Networks," 2025 IEEE International Conference on Computer, Electronics, Electrical Engineering & their Applications (IC2E3), Srinagar Garhwal, India, 2025, pp. 1-5, doi: 10.1109/IC2E365635.2025.11167073.
2. Y. Liu and E. Al-Masri, "Evaluating the Reliability of MQTT with Comparative Analysis," 2021 IEEE 4th International Conference on Knowledge Innovation and Invention (ICKII), Taichung, Taiwan, 2021, pp. 24-29, doi: 10.1109/ICKII51822.2021.9574783.
3. V. Dimov, E. Kirdan and M. -O. Pahl, "Resource tradeoffs for TLS-secured MQTT-based IoT Management," NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, Budapest, Hungary, 2022, pp. 1-6, doi: 10.1109/NOMS54207.2022.9789806.

• Authors have to explain the improvements for both of latency inflation, and cumulative energy growth while maintaining cryptographic protection the by deploying hybrid ECC–AES scheme.
• The presented results highlight that security configuration selection in IoT architectures should be evaluated through a multidimensional optimization lens rather than isolated metric comparison, which is not investigated throughout the course of the paper.
• Authors have to illustrate in more details the test setup and area of the presented experiments such as: number of nodes, dimension of the lab, battery of each node and its maximum output power, operating frequency,…etc.

 

 

 

Author Response

Dear

Editor

Digital

We are submitting the paper:

“Stability-Aware Security–Performance Trade-Off Analysis in Resource-Constrained IoT Systems: A Time-Series and Bootstrap-Based Evaluation of TLS and Hybrid ECC–AES Mechanisms”

Authored by: Carolina Del-Valle-Soto *, Maria Fernanda Alvarez Garcia, Ramon A Briseño, Jafet Rodríguez, and Paolo Visconti

We would like to thank the reviewers and editors for their detailed analysis of the manuscript; the comments are very valuable to us. In the revised version of the paper, we have incorporated the all changes recommended by the reviewers.

Comments to all observations and suggestions including point-by-point responses are addressed in the following text.

 

Reviewer 1 comments

Comment 1: The presented work presented a stability-aware and statistically robust evaluation of security–performance trade-offs in resource-constrained IoT systems.

The obtained results had been done through controlled experimentation on ESP32-based nodes, three communication configurations—unencrypted MQTT, MQTT over TLS 1.2, and a hybrid application-layer ECC–AES scheme—were compared across energy consumption, latency, and memory utilization. 

The obtained results did not compared to other references such as:

1. S. K. Chakravarty, A. Batra, N. Singh and G. Kumar, "The Effect of TLS Encryption on MQTT Protocol Security and Performance in Meteorological-IoT Networks," 2025 IEEE International Conference on Computer, Electronics, Electrical Engineering & their Applications (IC2E3), Srinagar Garhwal, India, 2025, pp. 1-5, doi: 10.1109/IC2E365635.2025.11167073.
2. Y. Liu and E. Al-Masri, "Evaluating the Reliability of MQTT with Comparative Analysis," 2021 IEEE 4th International Conference on Knowledge Innovation and Invention (ICKII), Taichung, Taiwan, 2021, pp. 24-29, doi: 10.1109/ICKII51822.2021.9574783.
3. V. Dimov, E. Kirdan and M. -O. Pahl, "Resource tradeoffs for TLS-secured MQTT-based IoT Management," NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, Budapest, Hungary, 2022, pp. 1-6, doi: 10.1109/NOMS54207.2022.9789806.

Response: We sincerely thank the reviewer for this valuable observation, which has helped us strengthen the positioning of our work within the current state of the art.

In response to this comment, we have substantially revised the Related Work section to explicitly incorporate and critically discuss the suggested references, namely Chakravarty et al. (2025), Liu and Al-Masri (2021), and Dimov et al. (2022). These studies have now been integrated into the manuscript with proper citation and contextual analysis.

More specifically, we have added a new paragraph in the Related Work section (see revised manuscript, Section 2) where these works are not only cited but also comparatively analyzed in terms of their methodological approach and evaluation scope. In particular:

• Chakravarty et al. (2025) is discussed in relation to TLS-induced overhead in MQTT-based IoT systems, especially regarding latency and energy consumption.
• Dimov et al. (2022) is incorporated to highlight resource trade-offs (memory and computational cost) associated with TLS-secured MQTT implementations in constrained environments.
• Liu and Al-Masri (2021) is referenced to contextualize reliability and performance variability in MQTT configurations.

Beyond citation, we have explicitly clarified the methodological differences between these studies and our work. While the referenced contributions provide important experimental insights, they generally rely on aggregate metrics, limited statistical validation, or protocol-level comparisons without accounting for temporal dependence in measurements.

To address this gap, our manuscript now explicitly emphasizes that the main contribution of this work lies in:

• The use of high-resolution (second-level) time-series measurements, enabling detailed analysis of transient and steady-state behavior.
• The incorporation of autocorrelation diagnostics and stationarity testing, ensuring correct modeling of temporal dependence.
• The application of block bootstrap inference, which provides statistically valid comparisons under serial correlation—an aspect not addressed in the cited works.
• The integration of a multi-objective Pareto frontier analysis, allowing a formal and quantitative characterization of the energy–latency trade-off.

Additionally, the comparative Table of Related Work (Table 1) has been expanded to include the three suggested references, clearly positioning them with respect to hardware validation, energy modeling depth, temporal stability analysis, and statistical rigor. This further highlights the methodological contribution of our approach relative to existing literature.

Comment 2: Authors have to explain the improvements for both of latency inflation, and cumulative energy growth while maintaining cryptographic protection the by deploying hybrid ECC–AES scheme.

Response: We thank the reviewer for this insightful comment, which highlights the importance of not only reporting performance improvements but also providing a clear mechanistic explanation of their origin.

In response, we have revised the Discussion section of the manuscript to include a detailed explanation of the underlying reasons why the hybrid ECC–AES scheme reduces both latency inflation and cumulative energy growth while maintaining cryptographic protection.

Specifically, we now clarify that the observed improvements are primarily due to differences in how cryptographic operations are distributed and executed in each approach. In TLS-based communication, the transport-layer security mechanism introduces a computationally intensive handshake phase involving certificate validation, asymmetric key exchange, and session establishment. This results in a significant initial latency increase and contributes to sustained processing overhead due to continuous encryption at the transport layer. Consequently, both latency dispersion and cumulative energy consumption increase over time.

In contrast, the hybrid ECC–AES scheme operates at the application layer and separates asymmetric and symmetric cryptographic operations. Elliptic Curve Cryptography (ECC) is used only during the initial key exchange, benefiting from reduced key sizes and lower computational complexity compared to traditional TLS handshakes. After this phase, AES-128 symmetric encryption is applied to the payload, which is significantly more efficient in terms of processing time and energy consumption. This design reduces the duration and intensity of the transient cryptographic overhead and minimizes steady-state computational load.

Furthermore, we emphasize that this architecture effectively decouples expensive cryptographic operations from continuous communication, thereby limiting repeated high-cost processing. As a result, the system maintains strong confidentiality guarantees while achieving lower latency variability and reduced cumulative energy growth. This mechanistic explanation is now explicitly included in the revised manuscript (Discussion section), directly supporting the empirical findings presented in the Results section.

Comment 3: The presented results highlight that security configuration selection in IoT architectures should be evaluated through a multidimensional optimization lens rather than isolated metric comparison, which is not investigated throughout the course of the paper.

Response: We thank the reviewer for this insightful observation, which has helped us improve the methodological consistency of the manuscript.

We agree that, in the original version, the concept of multidimensional optimization was primarily discussed in the Results and Conclusions sections without being explicitly formalized as part of the methodological framework. To address this issue, we have revised the manuscript to incorporate a rigorous multi-objective optimization formulation within the Materials and Methods section.

Specifically, we now define the evaluation of security configurations as a multi-objective optimization problem, where each communication scheme is represented as a vector of performance objectives, including cumulative energy consumption and end-to-end latency. Pareto dominance is formally introduced as the criterion for comparing configurations, allowing the identification of non-dominated solutions under conflicting objectives. This addition establishes a clear and mathematically grounded connection between the experimental design and the Pareto frontier analysis presented in the Results section.

Furthermore, the Conclusions section has been revised to explicitly reference this methodological formulation, ensuring consistency between the conceptual claims and the analytical framework employed throughout the study.

With these modifications, the manuscript now provides a coherent and rigorous treatment of security–performance trade-offs as a multidimensional optimization problem, rather than relying solely on independent metric comparisons.

Comment 4: Authors have to illustrate in more details the test setup and area of the presented experiments such as: number of nodes, dimension of the lab, battery of each node and its maximum output power, operating frequency,…etc.

Response: We thank the reviewer for this important comment, which highlights the need for a more detailed and reproducible description of the experimental setup.

In response, we have significantly expanded the Materials and Methods section to provide a comprehensive characterization of both the physical environment and the hardware configuration used in the experiments.

Specifically, the revised manuscript now includes:

• An explicit clarification that the experimental system consists of two ESP32-based nodes (emitter and receiver) communicating through a local MQTT broker.
• A detailed description of the laboratory environment, including approximate dimensions ($6 \times 4 \times 3$ meters) and controlled indoor conditions.
• Information on node placement and communication conditions, including fixed separation distance (3 meters) and line-of-sight configuration.
• Specification of the hardware platform (ESP32-WROOM-32), operating frequency (2.4 GHz ISM band), and WiFi standard (IEEE 802.11 b/g/n).
• Explicit indication of transmission power settings (configured to 20 dBm).
• Clarification of the power supply configuration, indicating that a regulated laboratory DC power source was used instead of batteries to ensure stable measurement conditions.
• Environmental control conditions, including temperature stabilization and absence of significant electromagnetic interference.

These additions are now included in the revised manuscript (Materials and Methods section, Experimental Configuration), ensuring that the experimental setup is fully transparent and reproducible.

We appreciate the reviewer’s suggestion, as it has strengthened the clarity, rigor, and reproducibility of the study.

 

Thank you very much.

Sincerely,

Carolina Del-Valle-Soto

Corresponding author

Universidad Panamericana. Facultad de Ingeniería. Álvaro del Portillo 49, Zapopan, Jalisco, 45010, México.

Phone: +52 (33) 13682200 | Ext. 4866

Email: cvalle@up.edu.mx

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

This manuscript presents a rigorous statistical evaluation of security-performance trade-offs in IoT nodes. By applying time-series diagnostics and block bootstrap resampling, the authors effectively compare energy and latency overheads across unencrypted, TLS, and hybrid ECC-AES communication schemes.

Overall, the statistical methodology is highly commendable and provides valuable insights. However, to achieve a full publication standard, the manuscript requires some revisions to address my following concerns.

1. The comparison between full TLS and the hybrid ECC-AES scheme is highly interesting but architecturally unequal. Please discuss how the absence of certificate-based trust in the hybrid scheme impacts the overall security context.
2. Evaluating TLS 1.2 provides a good baseline, but modern IoT heavily relies on TLS 1.3. Including a discussion or theoretical evaluation of TLS 1.3 would greatly enhance the contemporary relevance of your excellent findings.
3. The ESP32 platform offers dedicated cryptographic hardware accelerators. Kindly clarify whether your implementations utilize these hardware features or software libraries, as this significantly influences both energy consumption and latency results.
4. Relying on static firmware compilation for memory footprints is a good start. However, discussing dynamic heap allocation during the handshake phase would provide a much stronger evaluation of actual memory constraints.
5. The continuous ten-minute transmission window establishes a solid baseline. To strengthen practical applicability, please elaborate on how typical IoT sleep modes and duty cycling might alter your projected battery lifetime conclusions.
6. Applying stationarity tests over the entire window mixes the transient handshake phase with steady-state behavior. Separating these phases in your analysis would yield an even more precise statistical interpretation of the data.
7. Precise end-to-end latency calculations demand excellent clock synchronization between nodes. Please briefly describe the synchronization protocol utilized in your experimental setup to confirm the robustness of the reported delay measurements.
8. The energy peak during the TLS handshake heavily depends on certificate chain processing. Specifying the exact cipher suites, key dimensions, and certificate sizes used will perfectly ensure the reproducibility of your experiment.
9. The selection of the block length parameter twenty for your bootstrap resampling is reasonable. Providing a brief mathematical justification or threshold criterion for this specific value will further solidify your robust methodology.
10. The hybrid scheme shows great performance potential. Explicitly defining a formal threat model would help readers fully appreciate which specific adversarial capabilities this proposed operational compromise can successfully defend against.
11. The multi-objective Pareto frontier is a brilliant addition. I suggest adding a qualitative note regarding the trust-infrastructure dimension, acknowledging that TLS remains optimal when strict certificate-based authentication is a mandatory requirement.
12. Conducting tests in a controlled indoor environment minimizes random variables. A short discussion on how packet loss and retransmissions in harsher wireless environments might impact the TLS handshake overhead would be highly beneficial.

Author Response

Dear

Editor

Digital

We are submitting the paper:

“Stability-Aware Security–Performance Trade-Off Analysis in Resource-Constrained IoT Systems: A Time-Series and Bootstrap-Based Evaluation of TLS and Hybrid ECC–AES Mechanisms”

Authored by: Carolina Del-Valle-Soto *, Maria Fernanda Alvarez Garcia, Ramon A Briseño, Jafet Rodríguez, and Paolo Visconti

We would like to thank the reviewers and editors for their detailed analysis of the manuscript; the comments are very valuable to us. In the revised version of the paper, we have incorporated the all changes recommended by the reviewers.

Comments to all observations and suggestions including point-by-point responses are addressed in the following text.

 

Reviewer 2 comments

Comment 1: This manuscript presents a rigorous statistical evaluation of security-performance trade-offs in IoT nodes. By applying time-series diagnostics and block bootstrap resampling, the authors effectively compare energy and latency overheads across unencrypted, TLS, and hybrid ECC-AES communication schemes.

Overall, the statistical methodology is highly commendable and provides valuable insights. However, to achieve a full publication standard, the manuscript requires some revisions to address my following concerns.

The comparison between full TLS and the hybrid ECC-AES scheme is highly interesting but architecturally unequal. Please discuss how the absence of certificate-based trust in the hybrid scheme impacts the overall security context.

Response: We sincerely thank the reviewer for this insightful and technically important observation.

We fully agree that the comparison between TLS and the hybrid ECC–AES scheme is not architecturally equivalent in terms of trust establishment and security guarantees. In the original version of the manuscript, this distinction was not explicitly discussed, and we appreciate the reviewer for highlighting this critical aspect.

In response, we have revised the Discussion section to explicitly address the differences in the underlying trust models of the two approaches. In particular, we now clarify that:

• TLS relies on a certificate-based Public Key Infrastructure (PKI), which provides authenticated key exchange, endpoint identity verification, and protection against man-in-the-middle attacks through standardized trust chains.
• The hybrid ECC–AES scheme evaluated in this study does not include certificate-based authentication by default and therefore operates under a different trust assumption, typically requiring pre-shared trust or controlled deployment environments.

We further emphasize that, although both approaches ensure confidentiality and secure key exchange, they differ in their ability to guarantee endpoint authenticity and formal trust validation. As a result, the comparison presented in this work is explicitly framed as a performance-oriented evaluation under defined communication conditions, rather than a claim of full security equivalence.

This clarification has been incorporated into the revised manuscript (Discussion section), where we explicitly state that the suitability of each approach depends not only on performance metrics but also on system-level security requirements, including trust management and threat models.

Comment 2: Evaluating TLS 1.2 provides a good baseline, but modern IoT heavily relies on TLS 1.3. Including a discussion or theoretical evaluation of TLS 1.3 would greatly enhance the contemporary relevance of your excellent findings.

Response: We thank the reviewer for this valuable suggestion, which highlights the importance of considering the evolution of transport-layer security protocols in IoT systems.

We agree that TLS 1.3 represents the current state-of-the-art in secure communication and provides important performance improvements over TLS 1.2. In response to this comment, we have extended the Discussion section of the manuscript to include a theoretical analysis of TLS 1.3 and its expected impact on the observed results.

Specifically, we now discuss how TLS 1.3 introduces several architectural optimizations, including reduced handshake latency (fewer round trips), support for 0-RTT session resumption, and simplified cryptographic negotiation. These improvements are expected to reduce both latency overhead and computational cost compared to TLS 1.2.

However, we also clarify that TLS 1.3 retains key characteristics such as certificate-based authentication and transport-layer encryption, which continue to impose non-negligible computational and memory requirements in resource-constrained environments. Therefore, while TLS 1.3 would likely reduce the magnitude of the overhead observed in our experiments, the fundamental trade-off between security robustness and resource efficiency remains.

We have explicitly incorporated this discussion into the revised manuscript (Discussion section), and we also identify the experimental evaluation of TLS 1.3 under identical conditions as an important direction for future work.

Comment 3: The ESP32 platform offers dedicated cryptographic hardware accelerators. Kindly clarify whether your implementations utilize these hardware features or software libraries, as this significantly influences both energy consumption and latency results.

Response: We thank the reviewer for this important observation, which directly relates to the interpretation and reproducibility of the reported performance results.

In the revised manuscript, we have clarified the cryptographic implementation details in the Materials and Methods section. Specifically, all cryptographic operations in this study were implemented using the standard software libraries provided by the ESP-IDF framework (mbedTLS), without explicitly enabling low-level hardware acceleration features available on the ESP32 platform.

This approach was intentionally adopted to ensure consistency across all evaluated configurations and to reflect a common deployment scenario in embedded IoT systems, where developers rely on high-level cryptographic libraries rather than manually optimized hardware-specific implementations. As a result, the reported measurements capture the full software-level computational cost of the security mechanisms, including protocol overhead and memory management.

We acknowledge that hardware acceleration could reduce both latency and energy consumption, particularly for symmetric cryptographic operations such as AES. However, since both TLS and the hybrid ECC–AES scheme would benefit from such acceleration, we expect the relative performance relationships observed in this study to remain qualitatively consistent.

This clarification has been incorporated into the revised manuscript to improve transparency, reproducibility, and interpretability of the results. We also identify hardware-accelerated implementations as a relevant direction for future work.

Comment 4: Relying on static firmware compilation for memory footprints is a good start. However, discussing dynamic heap allocation during the handshake phase would provide a much stronger evaluation of actual memory constraints.

Response: We thank the reviewer for highlighting the importance of dynamic memory behavior in embedded cryptographic systems. In the revised manuscript, we have extended the Memory subsection in the Materials and Methods section to explicitly discuss the limitations of static firmware-based measurements.

We clarify that while Flash and RAM usage obtained from compilation provide a baseline estimate, they do not capture transient heap allocation occurring during runtime, particularly during TLS handshake operations. We further explain that TLS is expected to exhibit higher peak memory usage due to certificate processing and handshake state management, whereas the hybrid ECC–AES scheme imposes lower transient memory demand.

Although runtime heap profiling was not instrumented in this study, we state that the reported values should be interpreted as lower-bound estimates. The comparative conclusions remain valid, as dynamic memory overhead follows the structural complexity of each protocol. This clarification has been added to improve methodological rigor and transparency.

Comment 5: The continuous ten-minute transmission window establishes a solid baseline. To strengthen practical applicability, please elaborate on how typical IoT sleep modes and duty cycling might alter your projected battery lifetime conclusions.

Response: We thank the reviewer for this insightful comment. In the revised manuscript, we have extended the Discussion section to explicitly address the impact of duty cycling and low-power sleep modes on battery lifetime estimation.

We clarify that the experimental setup is based on a continuous transmission model, representing a worst-case scenario in terms of energy consumption. We then introduce a duty-cycle-based formulation of average current consumption, showing how the relative impact of security mechanisms scales with the fraction of active time.

We explain that while absolute energy differences decrease under low-duty-cycle operation, the relative ranking between TLS, ECC–AES, and unencrypted communication remains structurally consistent. This addition improves the practical applicability of the results and provides a more realistic interpretation for real-world IoT deployments.

Comment 6: Applying stationarity tests over the entire window mixes the transient handshake phase with steady-state behavior. Separating these phases in your analysis would yield an even more precise statistical interpretation of the data.

Response: We thank the reviewer for this important observation. We acknowledge that applying stationarity tests over the full time window may mix transient handshake dynamics with steady-state behavior.

In the revised manuscript, we clarify this point by explicitly discussing the presence of two distinct regimes: an initial transient phase and a steady-state communication phase. We explain that stationarity is more appropriately interpreted within the steady-state segment and that including the transient phase results in more conservative inference due to increased variance.

We have added a discussion on this limitation and outlined future work involving explicit segmentation methods such as change-point detection and windowed stationarity testing to further refine the statistical analysis.

Comment 7: Precise end-to-end latency calculations demand excellent clock synchronization between nodes. Please briefly describe the synchronization protocol utilized in your experimental setup to confirm the robustness of the reported delay measurements.

Response: The authors thank the reviewer for this important observation regarding time synchronization and its impact on latency accuracy.

In the experimental setup, both ESP32 nodes (emitter and receiver) were synchronized prior to each run using the Simple Network Time Protocol (SNTP) over the local network. Both devices referenced the same time source within the experimental infrastructure, ensuring a consistent temporal baseline before data acquisition. This synchronization step was performed immediately before initiating the transmission phase to minimize initial clock offset.

Given that all experiments were conducted within a controlled local network environment and over relatively short acquisition windows (10 minutes per run), clock drift between nodes is expected to be minimal. In addition, SNTP-based synchronization typically provides millisecond-level accuracy in such environments, which is sufficient for the temporal scale of the observed latency differences across configurations.

It is also important to note that the primary objective of the latency analysis is comparative rather than absolute. That is, all security configurations were evaluated under identical synchronization conditions, meaning that any residual synchronization error would systematically affect all measurements in a similar manner. Consequently, relative differences between TLS, ECC–AES, and unencrypted communication remain valid and are not biased by clock misalignment.

To address the reviewer’s concern, a clarification has been added in the latency subsection of the manuscript, explicitly describing the synchronization procedure and its implications for measurement robustness.

Comment 8: The energy peak during the TLS handshake heavily depends on certificate chain processing. Specifying the exact cipher suites, key dimensions, and certificate sizes used will perfectly ensure the reproducibility of your experiment.

Response: The authors thank the reviewer for this important observation regarding TLS handshake configuration.

In the revised manuscript, additional details have been included to clarify the cryptographic setup. The TLS implementation is based on the mbedTLS library within the ESP-IDF framework under TLS~1.2. The cipher suite was not explicitly fixed at the application level; instead, it was negotiated automatically according to the default configuration between the ESP32 client and the local MQTT broker.

The authentication process relied on a self-signed X.509 certificate with a 2048-bit RSA key and an approximate size of 1–2 kB. The certificate chain consisted of a single certificate, without intermediate authorities, which reflects a lightweight but realistic IoT deployment scenario.

While the exact negotiated cipher suite may vary, the dominant contributors to the energy peak during the TLS handshake are certificate parsing, signature verification, and asymmetric key exchange operations. Therefore, the measured transient energy behavior is primarily driven by these processes and is representative of practical TLS deployments in embedded systems.

Comment 9: The selection of the block length parameter twenty for your bootstrap resampling is reasonable. Providing a brief mathematical justification or threshold criterion for this specific value will further solidify your robust methodology.

Response: The authors thank the reviewer for this valuable observation. In the revised manuscript, a mathematical justification for the selected block length b=20b = 20b=20 has been included. The choice was based on the empirical autocorrelation structure of the time series. Specifically, the block size was selected to exceed the effective correlation length identified from the autocorrelation function (ACF).

The ACF analysis shows that statistically significant correlation persists up to approximately 10–15 lags, after which the autocorrelation decays toward zero. Therefore, selecting b=20b = 20b=20 ensures that each block captures the dominant temporal dependence structure (b>kcb > k_cb>kc​), which is a standard requirement for valid block bootstrap inference under weak dependence.

This choice also maintains a balance between preserving temporal correlation and ensuring a sufficient number of resampled blocks for stable variance estimation. The corresponding clarification has been added to the Time-Series Aware Inferential Testing subsection.

Comment 10: The hybrid scheme shows great performance potential. Explicitly defining a formal threat model would help readers fully appreciate which specific adversarial capabilities this proposed operational compromise can successfully defend against.

Response: We thank the reviewer for this valuable suggestion.

A formal threat model has been incorporated into the Materials and Methods section (after the Experimental Design subsection) to explicitly define the adversarial assumptions considered in this study.

The model assumes a network-level adversary with Dolev–Yao capabilities, including eavesdropping, message interception, modification, and replay, while remaining computationally bounded with respect to standard cryptographic primitives. Based on this framework, the security guarantees of TLS and the hybrid ECC–AES scheme are clearly differentiated.

In particular, TLS provides confidentiality, integrity, replay protection, and certificate-based authentication, whereas the hybrid scheme ensures payload confidentiality but operates under a pre-established trust assumption and does not inherently protect against strong man-in-the-middle attacks.

This clarification allows a more rigorous interpretation of the hybrid scheme as a performance-efficient solution under constrained trust models, rather than a full equivalent to TLS in adversarial environments.

Comment 11: The multi-objective Pareto frontier is a brilliant addition. I suggest adding a qualitative note regarding the trust-infrastructure dimension, acknowledging that TLS remains optimal when strict certificate-based authentication is a mandatory requirement.

Response: We thank the reviewer for this insightful observation.

A qualitative clarification has been added in the Results section immediately following the Pareto frontier analysis. Specifically, we explicitly state that the Pareto optimality identified in this study is defined with respect to energy and latency only, and does not account for trust-infrastructure requirements.

We further clarify that, although TLS is dominated in the energy–latency space, it remains the preferred solution in scenarios where certificate-based authentication and PKI integration are mandatory. This addition reinforces the interpretation of the hybrid scheme as a performance-efficient alternative under constrained trust assumptions, rather than a universal replacement for TLS.

Comment 12: Conducting tests in a controlled indoor environment minimizes random variables. A short discussion on how packet loss and retransmissions in harsher wireless environments might impact the TLS handshake overhead would be highly beneficial.

Response: We thank the reviewer for this valuable suggestion.

A discussion has been added in the Discussion section to explicitly address the impact of packet loss and retransmissions under harsher wireless conditions. We clarify that the experiments were conducted in a controlled indoor environment with negligible packet loss, and therefore the reported results represent a lower-bound estimate of protocol overhead.

We further explain that, in degraded wireless environments, TLS handshake operations may incur additional latency and energy cost due to retransmissions at the transport layer, potentially amplifying the observed overhead. This effect is discussed qualitatively without introducing unmeasured assumptions, and future work is proposed to experimentally evaluate performance under controlled packet loss scenarios.

 

Thank you very much.

Sincerely,

Carolina Del-Valle-Soto

Corresponding author

Universidad Panamericana. Facultad de Ingeniería. Álvaro del Portillo 49, Zapopan, Jalisco, 45010, México.

Phone: +52 (33) 13682200 | Ext. 4866

Email: cvalle@up.edu.mx

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

The paper’s most novel contribution is not “TLS vs lightweight crypto” per se (widely studied), but the stability-aware, dependence-aware evaluation design, including:

• second-level time-series measurements of current/energy,
• explicit autocorrelation and stationarity testing,
• block bootstrap inference to avoid i.i.d. assumptions,
• Pareto frontier analysis for joint energy–latency tradeoffs

Many prior works rely on aggregate averages, limited runs, and/or parametric testing without accounting for serial dependence, and rarely incorporate stability diagnostics at second-level resolution. The comparison table supports this positioning.

Suggestions for improvement:

1) The related work section becomes overly long and somewhat repetitive, including an extended narrative explanation of the conceptual framework that could be condensed.

2) Design: appropriate. Methods: mostly strong, but with key missing details. What needs to be clarified:

• Energy measurement instrumentation: the paper reports high-resolution current and energy, but it does not clearly specify what hardware meter/measurement circuit was used and how accuracy was ensured (sampling rate is shown, but not the instrument).
• Clock synchronization for one-way latency: end-to-end latency is computed via synchronized timestamps between emitter and receiver. The method of synchronization (NTP? local broker timestamping? shared clock source?) must be described because small time offsets can matter at the millisecond scale. 
• Security equivalence is not established: TLS provides confidentiality + integrity + authentication; the application-layer AES-128-CBC scheme as described primarily provides confidentiality unless integrity (e.g., HMAC/AEAD) and replay protection are implemented. The paper acknowledges this partially in Discussion but it must be operationally specified in Methods (what exactly is implemented, what threats are/aren’t covered).
• TLS configuration details: TLS overhead depends strongly on cipher suites, certificate validation, session resumption, and broker settings. TLS version is specified (1.2), but cipher suite and certificate chain settings should be included.

3) Results are generally clear and conclusions are broadly supported, with good use of figures and effect sizes. However, two interpretation risks remain:

• Security-performance tradeoff framing: the paper implicitly treats TLS vs hybrid as alternatives, but they offer different security properties unless the hybrid design includes integrity/authentication/replay defenses comparable to TLS. This should be explicit to avoid overclaiming that hybrid is “better” rather than “lower overhead under a different security envelope.”
• Battery lifetime extrapolation: the paper extrapolates 10-minute measurements to months of battery life assuming linearity and stable duty cycles. This can be acceptable as an illustrative estimate, but should be clearly framed as a rough projection requiring field validation. 

4) References are mostly relevant, but the reference list needs quality control. Issues observed:

• Several references contain placeholder DOIs or “XXXXXXX” which is not acceptable in a final submission.
• Duplicates appear (e.g., the same survey cited twice with slightly different formatting).
• Some references do not match their described scope (e.g., one entry labeled “TLS performance in constrained IoT” but the cited item appears to be about Bluetooth Low Energy). 

My recommendation to authors is to conduct a full reference audit: remove duplicates, fix incomplete DOI fields, and ensure each citation matches the claim it supports.

Author Response

Dear

Editor

Digital

We are submitting the paper:

“Stability-Aware Security–Performance Trade-Off Analysis in Resource-Constrained IoT Systems: A Time-Series and Bootstrap-Based Evaluation of TLS and Hybrid ECC–AES Mechanisms”

Authored by: Carolina Del-Valle-Soto *, Maria Fernanda Alvarez Garcia, Ramon A Briseño, Jafet Rodríguez, and Paolo Visconti

We would like to thank the reviewers and editors for their detailed analysis of the manuscript; the comments are very valuable to us. In the revised version of the paper, we have incorporated the all changes recommended by the reviewers.

Comments to all observations and suggestions including point-by-point responses are addressed in the following text.

 

Reviewer 3 comments

Comment 1: The paper’s most novel contribution is not “TLS vs lightweight crypto” per se (widely studied), but the stability-aware, dependence-aware evaluation design, including:

• second-level time-series measurements of current/energy,
• explicit autocorrelation and stationarity testing,
• block bootstrap inference to avoid i.i.d. assumptions,
• Pareto frontier analysis for joint energy–latency tradeoffs

Many prior works rely on aggregate averages, limited runs, and/or parametric testing without accounting for serial dependence, and rarely incorporate stability diagnostics at second-level resolution. The comparison table supports this positioning.

Suggestions for improvement:

The related work section becomes overly long and somewhat repetitive, including an extended narrative explanation of the conceptual framework that could be condensed.

Response: We thank the reviewer for this insightful observation.

The Related Work section has been revised to improve conciseness and reduce redundancy, particularly in the narrative description of the conceptual framework. The extended explanatory text has been condensed while preserving the essential structural relationships between IoT architecture, security mechanisms, performance dimensions, and statistical validation.

This revision enhances readability and clarity without removing any core conceptual contributions, and better aligns the section with the main methodological novelty of the paper.

Comment 2: Design: appropriate. Methods: mostly strong, but with key missing details. What needs to be clarified:

• Energy measurement instrumentation: the paper reports high-resolution current and energy, but it does not clearly specify what hardware meter/measurement circuit was used and how accuracy was ensured (sampling rate is shown, but not the instrument).
• Clock synchronization for one-way latency: end-to-end latency is computed via synchronized timestamps between emitter and receiver. The method of synchronization (NTP? local broker timestamping? shared clock source?) must be described because small time offsets can matter at the millisecond scale. 
• Security equivalence is not established: TLS provides confidentiality + integrity + authentication; the application-layer AES-128-CBC scheme as described primarily provides confidentiality unless integrity (e.g., HMAC/AEAD) and replay protection are implemented. The paper acknowledges this partially in Discussion but it must be operationally specified in Methods (what exactly is implemented, what threats are/aren’t covered).
• TLS configuration details: TLS overhead depends strongly on cipher suites, certificate validation, session resumption, and broker settings. TLS version is specified (1.2), but cipher suite and certificate chain settings should be included.

Response: We thank the reviewer for these detailed and constructive observations.

The manuscript has been revised to improve methodological transparency and reproducibility:

1) Energy measurement instrumentation has been explicitly described, including the use of a calibrated shunt-based measurement circuit and acquisition system.

2) Clock synchronization for one-way latency estimation has been clarified, specifying SNTP-based synchronization using a common local time reference.

3) The security properties of the hybrid ECC–AES scheme have been formally specified in the Threat Model section, explicitly distinguishing its confidentiality guarantees from the full security model provided by TLS.

4) Additional details regarding TLS configuration have been included, covering certificate type, key size, handshake behavior, and default cipher suite negotiation.

These revisions strengthen the methodological rigor and ensure that the experimental design can be accurately interpreted and reproduced.

Comment 3: Results are generally clear and conclusions are broadly supported, with good use of figures and effect sizes. However, two interpretation risks remain:

Security-performance tradeoff framing: the paper implicitly treats TLS vs hybrid as alternatives, but they offer different security properties unless the hybrid design includes integrity/authentication/replay defenses comparable to TLS. This should be explicit to avoid overclaiming that hybrid is “better” rather than “lower overhead under a different security envelope.”

Battery lifetime extrapolation: the paper extrapolates 10-minute measurements to months of battery life assuming linearity and stable duty cycles. This can be acceptable as an illustrative estimate, but should be clearly framed as a rough projection requiring field validation.

Response: Response:

We thank the reviewer for highlighting these important interpretation risks.

The manuscript has been revised to improve clarity and avoid overgeneralization:

1) The security–performance trade-off has been explicitly reframed in the Results and Conclusions sections to clarify that the hybrid ECC–AES scheme operates under a reduced security envelope compared to TLS. The comparison is now consistently presented as a trade-off between security scope and computational overhead, rather than implying direct superiority.

2) The battery lifetime extrapolation has been revised to clearly indicate that it represents an illustrative approximation based on short-term measurements. Additional text has been added to emphasize that real-world battery performance depends on duty cycles, environmental conditions, and system dynamics, and requires field validation.

These revisions ensure a more precise and scientifically grounded interpretation of the results.

Comment 4: References are mostly relevant, but the reference list needs quality control. Issues observed:

• Several references contain placeholder DOIs or “XXXXXXX” which is not acceptable in a final submission.
• Duplicates appear (e.g., the same survey cited twice with slightly different formatting).
• Some references do not match their described scope (e.g., one entry labeled “TLS performance in constrained IoT” but the cited item appears to be about Bluetooth Low Energy). 

My recommendation to authors is to conduct a full reference audit: remove duplicates, fix incomplete DOI fields, and ensure each citation matches the claim it supports.

Response: We thank the reviewer for this important observation regarding reference quality.

A full reference audit has been conducted to ensure accuracy and consistency. The following corrections have been implemented:

1) All placeholder DOIs have been removed or replaced with valid identifiers where available.

2) Duplicate entries referring to the same works have been consolidated into single consistent references.

3) All references have been manually verified to ensure alignment between the cited work and the claims they support. In particular, mismatches between described scope and actual content (e.g., BLE vs TLS-related studies) have been corrected.

These revisions ensure that the reference list meets publication standards and accurately supports the manuscript’s arguments.

 

 

Thank you very much.

Sincerely,

Carolina Del-Valle-Soto

Corresponding author

Universidad Panamericana. Facultad de Ingeniería. Álvaro del Portillo 49, Zapopan, Jalisco, 45010, México.

Phone: +52 (33) 13682200 | Ext. 4866

Email: cvalle@up.edu.mx

Author Response File: Author Response.pdf

Reviewer 4 Report

Comments and Suggestions for Authors

Not sure what Figure 1 is adding.  It is not bad, but the point of the figure is the relationship of the tasks, and those seemed clear to me from the text.

The temporal stability analysis column of Table 1 is not very useful when every item but one says "not addressed".  Could remove that column and just explain it in the text.

Figure 2 was not very clear.  The shaded region was not clear at all on my version.

Not sure Figure 4 says much.  Lots of white space to show a distribution with a confidence interval.

Figure 5 is great and clearly makes the point.

Figure 6 has the unclear shaded problem of Figure 2.  Shaded regions are not at all obvious.

I didn't check all of the references, but I thought the ones I checked were appropriate.

 

Author Response

Dear

Editor

Digital

We are submitting the paper:

“Stability-Aware Security–Performance Trade-Off Analysis in Resource-Constrained IoT Systems: A Time-Series and Bootstrap-Based Evaluation of TLS and Hybrid ECC–AES Mechanisms”

Authored by: Carolina Del-Valle-Soto *, Maria Fernanda Alvarez Garcia, Ramon A Briseño, Jafet Rodríguez, and Paolo Visconti

We would like to thank the reviewers and editors for their detailed analysis of the manuscript; the comments are very valuable to us. In the revised version of the paper, we have incorporated the all changes recommended by the reviewers.

Comments to all observations and suggestions including point-by-point responses are addressed in the following text.

 

Reviewer 4 comments

Comment 1: Not sure what Figure 1 is adding.  It is not bad, but the point of the figure is the relationship of the tasks, and those seemed clear to me from the text.

Response: We thank the reviewer for this observation.

We agree that the relationships illustrated in Figure 1 are described in the text. However, the purpose of the figure is not merely illustrative but structural: it provides a unified conceptual abstraction that integrates architectural constraints, security mechanisms, performance metrics, and statistical validation into a single analytical framework.

To clarify its contribution, we have revised both the description in the manuscript and the figure caption to explicitly state its role as a conceptual bridge between the literature review and the experimental methodology. This revision ensures that the figure adds interpretative value beyond the textual description.

Comment 2: The temporal stability analysis column of Table 1 is not very useful when every item but one says "not addressed".  Could remove that column and just explain it in the text.

Response: We thank the reviewer for this suggestion. We agree that the “Temporal Stability Analysis” column did not provide discriminative value, as most prior works do not address this aspect. Therefore, the column has been removed and the distinction is now explained more clearly in the text. This improves the clarity and readability of the table.

Comment 3: Figure 2 was not very clear.  The shaded region was not clear at all on my version.

Response: We thank the reviewer for this observation. We agree that the original visualization of the confidence interval using a shaded region reduced clarity, particularly in printed or compressed PDF formats.

To address this issue, Figure 2 has been redesigned to improve readability and visual contrast. Specifically:

• The shaded confidence region has been replaced by explicit upper and lower confidence interval bounds represented as dashed lines, which are more clearly distinguishable across viewing conditions.
• Individual experimental runs have been removed from the figure to reduce visual clutter and avoid obscuring the main statistical trends.
• The mean current profile is now emphasized using a thicker line, ensuring that the central tendency remains the dominant visual element.
• A mild moving-average smoothing has been applied solely for visualization purposes, improving interpretability without altering the underlying statistical properties.

Comment 4: Not sure Figure 4 says much.  Lots of white space to show a distribution with a confidence interval.

Response: We appreciate the reviewer’s observation. We agree that the original histogram-based representation did not efficiently communicate the key statistical insight and included unnecessary visual space.

To improve clarity and information density, Figure 4 has been redesigned as follows:

• The histogram has been replaced by a kernel density estimation (KDE), providing a smoother and more interpretable representation of the bootstrap distribution.
• The 95% confidence interval is now highlighted as a filled region under the density curve, making the inferential result visually explicit.
• The zero-reference line is preserved to directly illustrate that the confidence interval does not include zero.
• The figure layout has been compacted to reduce unused white space and improve visual balance.

Comment 5: Figure 5 is great and clearly makes the point.

Response: We appreciate the reviewer’s positive feedback. We are glad that Figure 5 clearly conveys the temporal dynamics and supports the interpretation of the security–performance differences observed across configurations.

Comment 6: Figure 6 has the unclear shaded problem of Figure 2.  Shaded regions are not at all obvious.

Response: We thank the reviewer for this valuable comment. We agree that the shaded confidence bands were not sufficiently visible in the original figure, particularly in the rendered PDF version.

To improve clarity and readability, the figure has been revised by replacing shaded regions with thin dotted confidence interval bounds around each cumulative energy curve. This representation enhances visibility, avoids visual clutter, and ensures interpretability both in color and grayscale formats.

The updated figure now clearly conveys the uncertainty information while preserving a clean and publication-quality presentation.

Comment 7: I didn't check all of the references, but I thought the ones I checked were appropriate.

Response: We sincerely thank the reviewer for this positive assessment of the reference selection. We are pleased that the references examined were found to be appropriate and relevant to the study.

 

 

Thank you very much.

Sincerely,

Carolina Del-Valle-Soto

Corresponding author

Universidad Panamericana. Facultad de Ingeniería. Álvaro del Portillo 49, Zapopan, Jalisco, 45010, México.

Phone: +52 (33) 13682200 | Ext. 4866

Email: cvalle@up.edu.mx

Author Response File: Author Response.pdf

Reviewer 5 Report

Comments and Suggestions for Authors

This paper presents a controlled experimental evaluation of three communication configurations implemented on ESP32-based nodes: unencrypted Message Queuing Telemetry Transport (MQTT), MQTT over TLS 1.2, and an application-layer hybrid scheme combining Elliptic Curve Diffie–Hellman key exchange with AES-128
encryption. Although the results are purely practical rather than scientific, they remain interesting. The paper is well-presented and the material is clearly presented, but there are a number of areas that require improvement.
1. Table 1 discusses relatively old sources; please update the material with more recent work.
2. Why were 5 experiments chosen (line 290)?
3. A more detailed description of the data used in the experiment is needed.
4. A table with the results is missing for clarity. 5. We need to describe in more detail what
1) MQTT without encryption,
2) MQTT over TLS 1.2,
3) MQTT with application-layer hybrid encryption (ECDH key exchange + AES-128
payload encryption) looks like.

Author Response

Dear

Editor

Digital

We are submitting the paper:

“Stability-Aware Security–Performance Trade-Off Analysis in Resource-Constrained IoT Systems: A Time-Series and Bootstrap-Based Evaluation of TLS and Hybrid ECC–AES Mechanisms”

Authored by: Carolina Del-Valle-Soto *, Maria Fernanda Alvarez Garcia, Ramon A Briseño, Jafet Rodríguez, and Paolo Visconti

We would like to thank the reviewers and editors for their detailed analysis of the manuscript; the comments are very valuable to us. In the revised version of the paper, we have incorporated the all changes recommended by the reviewers.

Comments to all observations and suggestions including point-by-point responses are addressed in the following text.

 

Reviewer 5 comments

Comment 1: this paper presents a controlled experimental evaluation of three communication configurations implemented on ESP32-based nodes: unencrypted Message Queuing Telemetry Transport (MQTT), MQTT over TLS 1.2, and an application-layer hybrid scheme combining Elliptic Curve Diffie–Hellman key exchange with AES-128
encryption. Although the results are purely practical rather than scientific, they remain interesting. The paper is well-presented and the material is clearly presented, but there are a number of areas that require improvement.

1. Table 1 discusses relatively old sources; please update the material with more recent work.

Response: We sincerely thank the reviewer for this valuable observation.

In response to the comment regarding Table 1, we have conducted a thorough update of the referenced literature to improve its relevance and timeliness. Specifically, several older or less representative sources have been replaced with more recent contributions (including works from 2023–2026) that better reflect the current state of research in IoT security and performance evaluation. These updates include recent studies on energy-aware cryptographic protocols, post-quantum TLS performance in constrained devices, and modern IoT security surveys.

In addition, we performed a broader reference audit across the manuscript to ensure consistency, remove redundancies, and improve the alignment between cited works and the claims they support. The revised Table 1 now provides a more up-to-date and representative overview of the literature, while preserving the comparative structure necessary to highlight the methodological gap addressed by this work.

Comment 2: Why were 5 experiments chosen (line 290)?

Response: We thank the reviewer for this insightful question.

The selection of five independent experimental runs was based on a balance between statistical reliability and practical feasibility in controlled embedded system experimentation. In this study, each run consists of a high-resolution time series (600 seconds at 1 Hz), which already provides a large number of observations per configuration. However, due to the presence of temporal autocorrelation, these samples cannot be treated as independent realizations. Therefore, the unit of statistical independence is the experimental run itself, rather than individual time samples.

From this perspective, multiple independent runs are required to assess reproducibility and to estimate inter-run variability. The choice of R=5R = 5R=5 runs follows common practice in experimental embedded systems research, where hardware constraints and execution time limit the number of full repetitions, while still allowing meaningful estimation of variability across independent executions.

Importantly, the adequacy of this number is empirically validated in the manuscript through the repeatability analysis (Figure 2), which shows that:

• the coefficient of variation across runs remains below 5%, and
• the confidence intervals derived from inter-run variability are narrow and stable.

These results indicate that the system behavior is highly reproducible and that additional runs would not significantly alter the estimated mean behavior or variability. In other words, convergence in the measured metrics is achieved with five repetitions under controlled conditions.

Furthermore, the inferential framework does not rely solely on inter-run replication. Instead, it integrates block bootstrap resampling within each time series to account for temporal dependence, thereby enhancing statistical robustness without requiring a large number of independent experimental runs.

To clarify this point, we have added an explicit justification in the revised manuscript explaining the rationale behind the choice of five repetitions and its validation through low inter-run variability and stable confidence intervals. The number of repetitions (R = 5) was selected based on empirical convergence of inter-run variability, as demonstrated by low coefficient of variation (<5%) and stable confidence intervals across runs.

Comment 3: A more detailed description of the data used in the experiment is needed.

Response: We thank the reviewer for this important comment.

We agree that a more explicit and structured description of the experimental data improves clarity, reproducibility, and scientific rigor. In the revised manuscript, we have expanded the description of the dataset to clearly define its structure, variables, and acquisition process.

Specifically, the experimental data consist of high-resolution time-series measurements collected from ESP32-based nodes under three security configurations. Each experimental run has a duration of 600 seconds with an effective sampling resolution of 1 Hz (after aggregation from 100 ms raw measurements), resulting in 600 observations per run and per device (emitter and receiver). With five independent repetitions per configuration, the dataset comprises a total of 3000 time-series observations per metric and configuration.

Each observation corresponds to a timestamped measurement of instantaneous current consumption I(t)I(t)I(t), from which accumulated energy E(t)E(t)E(t) is derived through numerical integration. In addition, latency measurements are recorded at the message level using synchronized timestamps between emitter and receiver nodes, producing a separate dataset of end-to-end delays LiL_iLi​. Memory usage metrics are obtained from firmware compilation outputs and represent static resource consumption (Flash and RAM).

The dataset can therefore be formally represented as a multivariate time series:

{I(t),E(t),Li,M},t=1,…,600,r=1,…,5\{I(t), E(t), L_i, M\}, \quad t = 1, \dots, 600, \quad r = 1, \dots, 5{I(t),E(t),Li​,M},t=1,…,600,r=1,…,5

where ttt indexes time within each run and rrr indexes independent experimental repetitions.

Importantly, due to temporal autocorrelation in second-level measurements, individual time samples are not treated as independent observations. Instead, statistical independence is defined at the level of experimental runs, and time-series dependence is explicitly handled through autocorrelation diagnostics and block bootstrap resampling.

Comment 4: A table with the results is missing for clarity. 5. We need to describe in more detail what
1) MQTT without encryption,

2) MQTT over TLS 1.2,

3) MQTT with application-layer hybrid encryption (ECDH key exchange + AES-128
payload encryption) looks like.

Response: We thank the reviewer for this valuable comment, which has helped improve both clarity and completeness of the manuscript.

First, regarding the presentation of results, we agree that a consolidated numerical summary enhances interpretability. While the original version emphasized graphical analysis to highlight temporal dynamics and variability, we have now incorporated a dedicated results table that summarizes the key performance metrics across all configurations. This table includes mean current consumption, cumulative energy, latency statistics, and memory usage, providing a clear and direct comparison between the evaluated security schemes.

Second, we acknowledge that the description of the evaluated communication configurations can benefit from a more explicit and structured presentation. To address this, we have expanded the manuscript by including a detailed comparative table that clearly defines the architectural and security characteristics of each configuration. Specifically, the revised version now explicitly describes the protocol stack, cryptographic operations, authentication mechanisms, and security guarantees associated with:
(i) unencrypted MQTT,

(ii) MQTT over TLS 1.2,

(iii) the hybrid ECC–AES application-layer scheme.

This addition clarifies the fundamental differences between transport-layer and application-layer security approaches, including their respective trust models, computational overhead, and security properties.

These improvements have been incorporated into the Materials and Methods section, ensuring a more transparent and reproducible description of both the experimental setup and the resulting performance evaluation.

 

 

Thank you very much.

Sincerely,

Carolina Del-Valle-Soto

Corresponding author

Universidad Panamericana. Facultad de Ingeniería. Álvaro del Portillo 49, Zapopan, Jalisco, 45010, México.

Phone: +52 (33) 13682200 | Ext. 4866

Email: cvalle@up.edu.mx

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

The authors have thoroughly and reasonably addressed all previous concerns. They significantly improved the manuscript by clarifying the distinct trust models of TLS and the hybrid ECC-AES scheme , detailing the software-based implementation , and adding valuable discussions on TLS 1.3 and duty-cycling. The revisions enhance the study's rigor. I recommend accepting this manuscript.

Reviewer 5 Report

Comments and Suggestions for Authors

The authors took into account all the comments and significantly finalized the article. The article may be recommended for publication.