Pith. sign in

REVIEW 3 major objections 4 minor 73 references

OTA-Key: Over the Air Key Management for Flexible and Reliable IoT Device Provision

T0 review · 3 major / 4 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper proposes OTA-Key, a two-stage scheme that gives every IoT device a unique key over the air without altering the existing production line.

desk verdict A concrete two-stage IoT provisioning scheme with a prototype, but the central security guarantee breaks because one extracted product key compromises every device. read the letter →

arxiv 2412.11564 v1 pith:JPR2PYHK submitted 2024-12-16 cs.CR cs.SE

Qian Zhang , Yi He , Yue Xiao , Xiaoli Zhang , Chunhua Song This is my paper · ORCID
classification cs.CRcs.SE
keywords IoTdeviceprovisioningover-the-airkeyupdateuniquekeystwo-stageatomicflashmemorystoragesharedproductagent-basedmanagement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

OTA-Key aims to solve a practical IoT security problem: vendors often install the same key in every device of a batch, so one extracted key can compromise thousands of devices. The paper argues that unique per-device keys are normally too costly because keys are baked into firmware and must be matched to device IDs on the production line. Its proposal is to decouple keys from firmware features: first burn identical firmware containing only a shared product key, then have an agent server issue a unique agent key and cloud key to each device over the air. The scheme also updates keys atomically, so a power failure or network drop during an update leaves the old key working. If this works, vendors get unique keys, cloud-platform switching, and mass key updates without changing the factory workflow.

What carries the argument

The load-bearing mechanism is a flash memory layout plus two protocols. The layout divides flash into key area A, a reserved redundant area B, and a feature firmware area: area A stores the agent key and the cloud key/connection information, while area B holds the incoming key during an update so the old key is never overwritten before the new one is confirmed. The two-stage provisioning protocol uses the shared product key only as a bootstrap credential to issue the unique agent key, after which the product key is erased. The atomic update protocol writes the new key to the redundant area, has the device confirm it, and only then tells the cloud to activate the new key and disable the old one, so an outage at any step leaves the previous key valid.

What would settle it

Extract the product key from the common firmware of a Stage-1 device, then run the agent-key request for a fresh device ID; if the agent issues a valid agent key and the cloud later accepts that impersonated identity, the paper's central security claim is falsified.

Watch

Extended reading notes

Core claim

OTA-Key's central claim is that per-device keys can be separated from the feature firmware stored in flash memory, with an intermediary agent server handling key allocation in two stages. In the first stage, the device manufacturer burns the same product key and identical feature firmware into every device, keeping the production line unchanged. In the second stage, the powered-on device uses that product key to request a unique agent key, erases the product key, and then uses the agent key to obtain a cloud key and connection information. Key updates follow an atomic protocol in which the new key is written to a reserved flash area before the old key is deactivated, so an interrupted update leaves the device usable. The paper uses formal protocol verification and head-to-head update-time and data-volume comparisons against firmware reflashing baselines to support the claims of security and lower overhead.

Load-bearing premise

The whole scheme depends on the shared product key staying secret, because anyone holding that key can run the provisioning protocol for a chosen device ID and receive that device's unique keys.

Editorial extensions

If this is right

  • A single common firmware image can serve an entire batch of devices, because each device's unique keys are assigned after burning, not embedded at compile time.
  • Interrupted key updates do not brick the device: the old key remains active until the new key is written, verified, and the cloud switches over.
  • Mass updates scale roughly linearly with fleet size and carry much less data than full or delta firmware reflashes, because only key material and connection information are transmitted.
  • Cloud-platform migration becomes a uniform firmware update followed by an agent-issued key update, rather than per-device firmware customization.
  • Extracting one device's unique key does not reveal the keys of the rest of the fleet.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A direct corollary the paper leaves implicit is that the same agent-mediated two-stage flow could issue short-lived certificates or rotating credentials, not just static symmetric keys, making periodic re-keying cheaper.
  • The paper's strongest untested exposure is the shared product key: if it leaks from the common firmware, any attacker can request unique keys for arbitrary device IDs; the proposed anomaly detection limits but does not eliminate that impersonation risk.
  • A testable extension would bind the first provisioning request to a per-chip secret already present in the device, so that knowing the product key alone is insufficient to claim a device identity.
  • The atomic write-to-reserved-area-then-activate pattern is a general recipe for constrained-device state updates and could be applied to configuration or firmware features beyond keys.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes OTA-Key, a manufacturing-time provisioning scheme in which devices are flashed with common firmware containing a shared product key (PK) and later receive unique agent keys and cloud keys over the air from an agent server. It also presents an atomic key-update protocol that uses a redundant flash area, a ProVerif model, a prototype on the STM32F429I-DISC1 board, and simulations comparing key-update time and data-transfer volume with firmware-update baselines. The claimed contributions are secure, scalable, flexible, and reliable large-scale distribution and updating of unique device keys without altering the existing production line.

Significance. If the security claim held, the two-stage architecture would be practically attractive: it avoids per-device firmware compilation and enables cloud-platform switching without returning devices to the manufacturer. The prototype implementation, power-consumption measurements, and included ProVerif source are concrete and support reproducibility. The performance comparison is useful as an engineering estimate. However, the central security claim is not established: the shared PK is the only bootstrap authentication secret, while the threat model explicitly allows device-key extraction, and the ProVerif model assumes the secrecy it is supposed to prove. The engineering contribution is real, but the paper's advertised security guarantee is not supported under its own assumptions.

major comments (3)
  1. [§III-A, §III-B, §IV-A, Fig. 4] The security goal in §III-B requires that compromise of some device keys cannot escalate to large-scale key exposure, and §III-A explicitly grants attackers the ability to obtain 'a limited number of device keys through reverse engineering.' Yet the first provisioning stage uses a single product key PK shared by all devices as the only authentication secret, as shown in Fig. 4, step 1, where the device sends PO and Enc(PK, ID||Nonce1). An attacker who extracts PK from one device can choose an arbitrary device ID, run the same protocol, and receive that device's unique AK in step 2; with AK, the attacker can then run the Fig. 5 cloud-key update and obtain the device's cloud key. This directly violates the §III-B escalation-prevention goal. Section VII's anomaly detection is a post-hoc response that may detect some mass assignments, but it does not prevent the compromise, and its statement that 'the PK would not leak unless there is an insider threat within either the DM or IoT vendor' introduces a trust assumption that is absent from §III-A. The claim in §V-A that the scheme is secure is therefore not supported under the paper's own threat model.
  2. [§V-A, Listing 1] The ProVerif model assumes away the property at issue. Listing 1 declares 'free PK: key [private]' and 'free AK: key [private]', and the queries include 'attacker(PK)' and 'attacker(AK)'; proving 'not attacker(PK[])' in such a model is equivalent to assuming that PK is never divulged, which is exactly the secret whose resilience to device compromise is the paper's main security goal. The model also does not include a corrupted-device role that knows PK and can choose arbitrary IDs, and it does not generate a unique AK per device instance. Consequently, Listing 2's 'true' results cannot be cited as evidence against the escalation attack described in the previous comment.
  3. [§V-A, Listing 1] Independently of the PK issue, the formal verification covers only the agent-key initialization procedure of Fig. 4; the cloud-key update procedure of Fig. 5 is not modeled in ProVerif, yet §V-A concludes that 'our protocol design ensures the security of these keys' for the overall scheme. The security of the Fig. 5 protocol is asserted rather than verified, and it inherits the same dependence on AK secrecy that was not established under the paper's threat model.
minor comments (4)
  1. [§IV-B, Figs. 4-5] The notation 'HMAC(AK, *)' is used in both figures with different meanings for '*'; specify the exact concatenated byte strings in each message to avoid ambiguity.
  2. [§VII, Table V] The scalability numbers in Table V appear inconsistent with the stated per-batch estimate: at 5 minutes per 100 devices, 300 devices should take 15 minutes, not 16, and 1000 devices should take 50 minutes, not 55; clarify whether the differences come from the 3-4 minute check time or from an additional overhead parameter.
  3. [§V-D] The sentence 'we verified that the firmware received by the device matches the original firmware' is unclear because the described experiments do not transfer firmware; if this refers to a separate integrity check, describe the check and its results.
  4. [§V-C] The statement that splitting the firmware before transmission gives no advantage in Fig. 7 is only true because no transmission failure rate is modeled in that subsection; make this assumption explicit.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: OTA-Key's protocol design is evaluated by an independent formal model and external performance baselines; the security-verification gap is a threat-model mismatch, not a circular reduction.

full rationale

I walked the claimed derivation chain of OTA-Key. The scheme is an engineering construction, not a derived mathematical theorem: no parameter is fitted to data and then reported as a prediction, and the performance comparisons against BL1-BL4 are externally benchmarked. The one candidate for circularity is the ProVerif verification: Listing 1 declares 'free PK: key [private]' and 'free AK: key [private]', and Listing 2 reports 'Query not attacker(PK[]) is true.' This is a standard protocol-secrecy proof: the private declarations are the initial secrecy assumptions, and the attacker queries are the properties being checked, so the proof does not reduce to its own conclusion by construction. However, there is a genuine mismatch between the formal model and the threat model: Section III-A grants attackers the ability to access a limited number of device keys through reverse engineering, while Section VII later asserts that the product key 'would not leak unless there is an insider threat within either the DM or IoT vendor.' The ProVerif model does not include a device-key-extraction or PK-leakage capability, so the formal result supports secrecy only in a model where PK and AK remain private. This is an assumption/correctness gap in the paper's security claim, not a circularity. Self-citations in the paper (e.g., references [5], [9], [27], [29], [48], [53]) are used as background motivation and related work; none is load-bearing for the correctness of OTA-Key's two-stage provisioning or atomic update protocols. The central protocol design is self-contained and independently evaluated, so the circularity score is 0.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The scheme introduces no new physical or conceptual entities beyond the agent server, which is a standard architectural role. The key assumptions are about the secrecy of the shared product key and the trustworthiness of the agent, both of which are load-bearing for the security claim.

free parameters (3)
  • Check time per 100 devices = 180 seconds
    Used in Section VII scalability analysis to estimate OTA-Key total time. The paper states this is based on experiments, but no supporting data is shown, and it dominates the OTA-Key time budget.
  • Transmission failure rate = 5%
    Assumed in Section V-D for all schemes. No justification or sensitivity analysis is provided.
  • Network bandwidth for large-scale test = 6.5 MBps
    Assumed in Section V-D. A different bandwidth would change the absolute times, though the relative comparison would remain similar.
assumptions (4)
  • ad hoc to paper The product key (PK) is pre-installed on both device and agent and remains secret during provisioning.
    Invoked in Section IV-A to secure the first two messages. Contradicts the threat model in Section III-A, where attackers can extract device keys via reverse engineering.
  • domain assumption The agent server is trusted and cannot be compromised.
    Section VII states attackers cannot compromise the Agent. If the Agent is compromised, all device keys and cloud keys are exposed.
  • domain assumption The IoT device manufacturer is honest-but-curious and will not run the provisioning protocol itself with the extracted PK.
    Section III-A categorizes manufacturers as honest-but-curious, but the scheme gives them PK and physical access to devices, so a curious manufacturer could request unique keys for any device.
  • domain assumption Flash memory writes are atomic and a partially written key never becomes active.
    The atomic update method in Section IV-B relies on writing to a redundant area then activating the new key. The paper does not specify how activation is marked or how crash consistency is enforced at the flash level.

how reviews work

0 comments
Cite this review

Pith. "Pith review of OTA-Key: Over the Air Key Management for Flexible and Reliable IoT Device Provision." pith.science (2026). https://pith.science/paper/JPR2PYHK

@misc{pith2026241211564,
  author       = {Pith},
  title        = {Pith review of: OTA-Key: Over the Air Key Management for Flexible and Reliable IoT Device Provision},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JPR2PYHK}},
  note         = {Machine review of arXiv:2412.11564}
}
read the original abstract

As the Internet of Things (IoT) industry advances, the imperative to secure IoT devices has become increasingly critical. Current practices in both industry and academia advocate for the enhancement of device security through key installation. However, it has been observed that, in practice, IoT vendors frequently assign shared keys to batches of devices. This practice can expose devices to risks, such as data theft by attackers or large-scale Distributed Denial of Service (DDoS) attacks. To address this issue, our intuition is to assign a unique key to each device. Unfortunately, this strategy proves to be highly complex within the IoT context, as existing keys are typically hardcoded into the firmware, necessitating the creation of bespoke firmware for each device. Furthermore, correct pairing of device keys with their respective devices is crucial. Errors in this pairing process would incur substantial human and temporal resources to rectify and require extensive communication between IoT vendors, device manufacturers, and cloud platforms, leading to significant communication overhead. To overcome these challenges, we propose the OTA-Key scheme. This approach fundamentally decouples device keys from the firmware features stored in flash memory, utilizing an intermediary server to allocate unique device keys in two distinct stages and update keys. We conducted a formal security verification of our scheme using ProVerif and assessed its performance through a series of evaluations. The results demonstrate that our scheme is secure and effectively manages the large-scale distribution and updating of unique device keys. Additionally, it achieves significantly lower update times and data transfer volumes compared to other schemes.

Figures

Figures reproduced from arXiv: 2412.11564 by the authors.

Figure 1
Figure 1. Current Production Line. management to an independent agent. The agent distributes and updates unique device keys on a large scale over the air, eliminating the need for a wired connection (such as ST-Link or JTAG). This process does not alter the existing production line while also supporting flexible updates of these unique keys. Technical Challenges and Solution: It is non-trivial to design and implement OTA-key.… view at source ↗
Figure 2
Figure 2. Our Design. prevent data monopolization by large cloud platforms. This regulation underscores the need for updating device keys to enhance flexibility and security. We conduct an extensive survey of industrial practices and academic literature, summarizing the results in Table I. This table shows that existing methods achieve either security or scalability; however, none provide the flexibility required to switch cl… view at source ↗
Figure 3
Figure 3. Flash memory structure design. to storing the unique agent key; the subsequent 16KB, from 0x08001000 to 0x08004FFF, stores the cloud key and cloud connection addresses. Following area A, an additional 18KB (from 0x08005000 to 0x08009CFF), designated as area B, is reserved as redundancy space to support atomic updates of keys. The remaining portion of the flash memory is used to store the feature firmware, which is i… view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Agent key initialization procedure. retrieves the ID. Subsequently, the agent sends Enc(PK, AK||Nonce1||Nonce2), along with HMAC(AK, *), where ‘*’ represents ‘AK||Nonce1||Nonce2’. 3) The device decrypts the information using PK to obtain the unique agent key and verifi…
Figure 5
Figure 5. Figure 5: Cloud key update procedure. Old Key Unique agent key Unique cloud key Downloading... Same Feature Firmware Downloading... New key Erased Erased Unique cloud key Same Feature Firmware Unique agent key 0x08000FFF 0x08000800 0x08004FFF 0x08001000 0x081FFFFF 0x08005800 0x0…
Figure 6
Figure 6. Figure 6: Flash memory state during key update. 6) The cloud, upon receiving the agent’s notification, ac￾tivates the new cloud key and connection information and disables the old ones. Steps 5-6 involve the agent sending commands to the cloud to enable the new key and disable t…
Figure 7
Figure 7. Figure 7: Key update time for a single device with different firmware sizes [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Comparison of time required to complete a single key update for all [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Comparison of data volume required to complete a single key update [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

73 extracted references · 71 canonical work pages

  1. [1]

    [Online]

    Intelligently connecting our world in the 5g era. [Online]. Available: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/ documents/intelligently connecting our world in the 5g era web 1. pdf

    work page

  2. [2]

    R. Shewale. How many iot devices are there(2024-2032). Blog. [Online]. Available: https://www.demandsage.com/number-of-iot-devices/

    work page 2024

  3. [3]

    [Online]

    Millions of IoT Devices Using Same Hard-Coded CRYPTO Keys. [Online]. Available: https://thehackernews.com/2015/11/ iot-device-crypto-keys.html

    work page 2015

  4. [4]

    Your firmware has arrived: A study of firmware update vulnerabilities,

    Y . Wu, J. Wang, Y . Wang, S. Zhai, Z. Li, Y . He, K. Sun, Q. Li, and N. Zhang, “Your firmware has arrived: A study of firmware update vulnerabilities,” in USENIX Security Symposium , 2024

    work page 2024

  5. [5]

    Demystifying the security implications in iot device rental services,

    Y . He, Y . Guan, R. Lun, S. Song, Z. Guo, J. Zhuge, J. Chen, Q. Wei, Z. Wu, M. Yu, S. Hetian, and Q. Li, “Demystifying the security implications in iot device rental services,” in USENIX Security, 2024

    work page 2024

  6. [6]

    [Online]

    Mirai Botnet. [Online]. Available: https://web.archive. org/web/20161212084605/https://www.cyber.nj.gov/threat-profiles/ botnet-variants/mirai-botnet

    work page arXiv

  7. [7]

    Discovering and understanding the security hazards in the interactions between IoT devices, mobile apps, and clouds on smart home platforms,

    W. Zhou, Y . Jia, Y . Yao, L. Zhu, L. Guan, Y . Mao, P. Liu, and Y . Zhang, “Discovering and understanding the security hazards in the interactions between IoT devices, mobile apps, and clouds on smart home platforms,” in 28th USENIX Security Symposium (USENIX Security 19) , 2019

    work page 2019

  8. [8]

    Intel® SDO

    Manual configuration takes 20 minutes per device. Intel® SDO. [Online]. Available: https://www.intel.com/content/www/us/en/ developer/tools/secure-device-onboard/overview.html

    work page

Show all 73 references
  1. [9]

    RapidPatch: Firmware hotpatching for Real-Time embedded devices,

    Y . He, Z. Zou, K. Sun, Z. Liu, K. Xu, Q. Wang, C. Shen, Z. Wang, and Q. Li, “RapidPatch: Firmware hotpatching for Real-Time embedded devices,” in Usenix Security Symposium , 2022

    2022

  2. [10]

    [Online]

    Changhong Sichuan Changhong Electric Co., Ltd. [Online]. Available: https://cn.changhong.com/

  3. [11]

    [Online]

    HiSilicon | Smart Devices for All Scenarios. [Online]. Available: https://www.hisilicon.com/en

  4. [12]

    [Online]

    Yiqi yiqi intelligent control yiqi intelligent control is an intelligent and versatile controller. [Online]. Available: http://www.iyqzk.cn/

  5. [13]

    Reboot-oriented iot: Life cycle management in trusted execution environment for dis- posable iot devices,

    K. Suzaki, A. Tsukamoto, A. Green, and M. Mannan, “Reboot-oriented iot: Life cycle management in trusted execution environment for dis- posable iot devices,” in Proc. of Annual Computer Security Applications Conference, 2020, pp. 428–441

    2020

  6. [14]

    Resilient, Auditable, and Secure IoT-Enabled Smart Inverter Firmware Amendments With Blockchain,

    R. Akkaoui, A. Stefanov, P. Palensky, and D. H. J. Epema, “Resilient, Auditable, and Secure IoT-Enabled Smart Inverter Firmware Amendments With Blockchain,” IEEE Internet of Things Journal , vol. 11, no. 5, pp. 8945–8960, Mar. 2024. [Online]. Available: https://ieeexplore.ieee...

    2024

  7. [15]

    ASSURED: Architecture for Secure Software Update of Realistic Embedded Devices,

    N. Asokan, T. Nyman, N. Rattanavipanon, A.-R. Sadeghi, and G. Tsudik, “ASSURED: Architecture for Secure Software Update of Realistic Embedded Devices,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , vol. 37, no. 11, pp. 2290–2300, Nov. 2018, co...

    2018

  8. [16]

    Dominance as a New Trusted Computing Primitive for the Internet of Things,

    M. Xu, M. Huber, Z. Sun, P. England, M. Peinado, S. Lee, A. Marochko, D. Mattoon, R. Spiger, and S. Thom, “Dominance as a New Trusted Computing Primitive for the Internet of Things,” in 2019 IEEE Symposium on Security and Privacy (SP) , May 2019, pp. 1415–1430, iSSN: 2375-1207...

    2019

  9. [17]

    Design and Implementation of MQTT- Based Over-the-Air Updating Against Curious Brokers,

    N.-Z. Wang and H.-Y . Chien, “Design and Implementation of MQTT- Based Over-the-Air Updating Against Curious Brokers,” IEEE Internet of Things Journal , vol. 11, no. 6, pp. 10 768–10 777, Mar. 2024, conference Name: IEEE Internet of Things Journal. [Online]. Available: https:/...

    2024

  10. [18]

    UpKit: An Open-Source, Portable, and Lightweight Update Framework for Constrained IoT Devices,

    A. Langiu, C. A. Boano, M. Schuß, and K. R ¨omer, “UpKit: An Open-Source, Portable, and Lightweight Update Framework for Constrained IoT Devices,” in 2019 IEEE 39th International Conference on Distributed Computing Systems (ICDCS) , Jul. 2019, pp. 2101– 2112, iSSN: 2575-8411. ...

    2019

  11. [19]

    bird offers shared electric scooters available in various cities across the us, europe, and the middle east

    Bird. bird offers shared electric scooters available in various cities across the us, europe, and the middle east. [Online]. Available: https://www.bird.co/how/

  12. [20]

    lime is the world’s largest shared electric vehicle company

    Lime. lime is the world’s largest shared electric vehicle company. [Online]. Available: https://www.li.me/why

  13. [21]

    [Online]

    Didi didi green orange-didi official website. [Online]. Available: https://www6.didiglobal.com/travel-service/bike

  14. [22]

    [Online]

    AWS Device Provision. [Online]. Available: https://docs.aws.amazon. com/iot/latest/developerguide/provision-wo-cert.html

  15. [23]

    https://learn.microsoft.com/ en-us/azure/iot-dps/about-iot-dps

    Azure IoT Device Provisioning Service. https://learn.microsoft.com/ en-us/azure/iot-dps/about-iot-dps. [Online]. Available: https://learn. microsoft.com/en-us/azure/iot-dps/about-iot-dps

  16. [24]

    [Online]

    Aliyun. [Online]. Available: https://help.aliyun.com/zh/iot/user-guide/ unique-certificate-per-device-verification?spm=a2c4g.11186623.0.0. 3fe917503vVwZ5

  17. [25]

    A Comprehensive Study of Security of Internet-of-Things,

    A. Mosenia and N. K. Jha, “A Comprehensive Study of Security of Internet-of-Things,” IEEE Transactions on Emerging Topics in Computing, vol. 5, pp. 586–602, Oct. 2017, conference Name: IEEE Transactions on Emerging Topics in Computing. [Online]. Available: https://ieeexplore.i...

    2017

  18. [26]

    Secure firmware Over-The-Air updates for IoT: Survey, challenges, and discussions,

    S. El Jaouhari and E. Bouvet, “Secure firmware Over-The-Air updates for IoT: Survey, challenges, and discussions,” Internet of Things , vol. 18, p. 100508, May 2022. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S2542660522000142

    2022

  19. [27]

    Ruledger: Ensuring execution integrity in trigger-action iot platforms,

    J. Fan, Y . He, B. Tang, Q. Li, and R. Sandhu, “Ruledger: Ensuring execution integrity in trigger-action iot platforms,” in IEEE INFOCOM 2021 - IEEE Conference on Computer Communications, 2021, pp. 1–10

    2021

  20. [28]

    [Online]

    EU Draft Proposal (Data Act): Facilitate Switching Between Cloud and Edge Services. [Online]. Available: https://eur-lex.europa.eu/ legal-content/EN/TXT/PDF/?uri=CELEX:52022PC0068&from=EN

  21. [29]

    Your firmware has arrived: A study of firmware update 14 vulnerabilities,

    Y . Wu, J. Wang, Y . Wang, S. Zhai, Z. Li, Y . He, K. Sun, Q. Li, and N. Zhang, “Your firmware has arrived: A study of firmware update 14 vulnerabilities,” in 33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 5627–5644

    2024

  22. [30]

    Toward the analysis of embedded firmware through automated re- hosting,

    E. Gustafson, M. Muench, C. Spensky, N. Redini, A. Machiry, Y . Fratan- tonio, D. Balzarotti, A. Francillon, Y . R. Choe, C. Kruegel et al. , “Toward the analysis of embedded firmware through automated re- hosting,” in 22nd International Symposium on Research in Attacks, Intru...

    2019

  23. [31]

    SafetyPin: En- crypted backups with Human-Memorable secrets,

    E. Dauterman, H. Corrigan-Gibbs, and D. Mazi `eres, “SafetyPin: En- crypted backups with Human-Memorable secrets,” in Proceedings of the 14th USENIX Symposium on Operating Systems Design and Imple- mentation (OSDI 20) , 2020, pp. 1121–1138

    2020

  24. [32]

    [On- line]

    Intel® software guard extensions (intel® sgx). [On- line]. Available: https://www.intel.com/content/www/us/en/products/ docs/accelerator-engines/software-guard-extensions.html

  25. [33]

    A Framework for Orchestrating Secure and Dynamic Access of IoT Services in Multi-Cloud Environments,

    M. Kazim, L. Liu, and S. Y . Zhu, “A Framework for Orchestrating Secure and Dynamic Access of IoT Services in Multi-Cloud Environments,” IEEE Access , vol. 6, pp. 58 619–58 633, 2018, conference Name: IEEE Access. [Online]. Available: https://ieeexplore. ieee.org/abstract/docu...

    2018

  26. [34]

    A Scalable Multicloud Storage Architecture for Cloud-Supported Medical Internet of Things,

    R. Cao, Z. Tang, C. Liu, and B. Veeravalli, “A Scalable Multicloud Storage Architecture for Cloud-Supported Medical Internet of Things,” IEEE Internet of Things Journal , vol. 7, no. 3, pp. 1641–1654, Mar. 2020, conference Name: IEEE Internet of Things Journal. [Online]. Avail...

    2020

  27. [35]

    [Online]

    Read unique device ID from STM32F410 reference manual. [Online]. Available: https://www.st.com/resource/en/reference manual/ rm0401-stm32f410-advanced-armbased-32bit-mcus-stmicroelectronics. pdf

  28. [36]

    A Provably Secure True Random Number Generator with Built-In Tolerance to Active Attacks,

    B. Sunar, W. Martin, and D. Stinson, “A Provably Secure True Random Number Generator with Built-In Tolerance to Active Attacks,” IEEE Transactions on Computers , vol. 56, no. 1, pp. 109–119, Jan. 2007. [Online]. Available: http://ieeexplore.ieee.org/document/4016501/

    2007

  29. [37]

    Classification of pseudo-random number generators applied to information security,

    I. V . Chugunkov, M. A. Ivanov, E. A. Gridneva, and N. Y . Shestakova, “Classification of pseudo-random number generators applied to information security,” in 2017 IEEE Conference of Russian Young Researchers in Electrical and Electronic Engineering (EIConRus), Feb. 2017, pp. ...

    2017

  30. [38]

    [Online]

    D-Link | Technical Support | Downloads. [Online]. Available: https://tsd.dlink.com.tw/ddetail

  31. [39]

    [Online]

    DS-2CD2523G0-IS firmware download. [Online]. Available: http: //www.hikvision.com/en/support/download/firmware/

  32. [40]

    [Online]

    DJI Firmware Download. [Online]. Available: https://www.dji.com/cn/ downloads/softwares/dji-assistant-2-consumer-drones-series

  33. [41]

    [Online]

    Insta360onerfw Firmware Download. [Online]. Available: https: //www.insta360.com/download/enterprise

  34. [42]

    Energy-Efficient Progressive Remote Update for Flash-Based Firmware of Networked Embedded Systems,

    J. Kim and P. H. Chou, “Energy-Efficient Progressive Remote Update for Flash-Based Firmware of Networked Embedded Systems,” ACM Transactions on Design Automation of Electronic Systems , vol. 16, no. 1, pp. 1–26, Nov. 2010. [Online]. Available: https: //dl.acm.org/doi/10.1145/1...

    2010

  35. [43]

    Universal framework for remote firmware updates of low-power devices,

    O. Kachman, M. Balaz, and P. Malik, “Universal framework for remote firmware updates of low-power devices,” Computer Communications, vol. 139, pp. 91–102, May 2019. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0140366418307722

    2019

  36. [44]

    HJSplit - Download

    “HJSplit - Download.” [Online]. Available: https://hjsplit.en.softonic. com/

  37. [45]

    Resumable Downloads with HTTP Range | Fullstack.wiki

    “Resumable Downloads with HTTP Range | Fullstack.wiki.” [Online]. Available: https://fullstack.wiki/http/resumable-downloads

  38. [46]

    [Online]

    V ´elib’ 2024 number of e-bike is about 20K. [Online]. Available: https://www.extrabux.com/chs/guide/8312464

    2024

  39. [47]

    Time-to-provision evaluation of iot devices using automated zero-touch provisioning,

    I. Bo ˇskov, H. Yetgin, M. Vu ˇcnik, C. Fortuna, and M. Mohor ˇciˇc, “Time-to-provision evaluation of iot devices using automated zero-touch provisioning,” in IEEE Global Communications Conference , 2020, pp. 1–7

    2020

  40. [48]

    Blueswat: A lightweight state-aware security framework for bluetooth low energy,

    X. Che, Y . He, X. Feng, K. Sun, K. Xu, and Q. Li, “Blueswat: A lightweight state-aware security framework for bluetooth low energy,” in CCS, 2024

    2024

  41. [49]

    [Online]

    Alibaba Cloud IoT Device provision. [Online]. Available: https://www.alibabacloud.com/help/en/iot/user-guide/ unique-certificate-per-device-verification?spm=a2c63.p38356.0.0. 18d87734405Obc

  42. [50]

    IoT security: Review, blockchain solutions, and open challenges,

    M. A. Khan and K. Salah, “IoT security: Review, blockchain solutions, and open challenges,” Future Generation Computer Systems , vol. 82, pp. 395–411, May 2018. [Online]. Available: https: //linkinghub.elsevier.com/retrieve/pii/S0167739X17315765

    2018

  43. [51]

    Secure Remote User Authenticated Key Establishment Protocol for Smart Home Environment,

    M. Wazid, A. K. Das, V . Odelu, N. Kumar, and W. Susilo, “Secure Remote User Authenticated Key Establishment Protocol for Smart Home Environment,” IEEE Transactions on Dependable and Secure Computing, vol. 17, no. 2, pp. 391–406, Mar. 2020, conference Name: IEEE Transactions o...

    2020

  44. [52]

    Anonymous Lightweight Chaotic Map-Based Authenticated Key Agreement Protocol for Industrial Internet of Things,

    J. Srinivas, A. K. Das, M. Wazid, and N. Kumar, “Anonymous Lightweight Chaotic Map-Based Authenticated Key Agreement Protocol for Industrial Internet of Things,” IEEE Transactions on Dependable and Secure Computing , vol. 17, no. 6, pp. 1133–1146, Nov. 2020, conference Name: I...

    2020

  45. [53]

    From Hardware Fingerprint to Access Token: Enhancing the Authentication on IoT Devices,

    Y . Xiao, Y . He, X. Zhang, Q. Wang, R. Xie, K. Sun, K. Xu, and Q. Li, “From Hardware Fingerprint to Access Token: Enhancing the Authentication on IoT Devices,” in Proceedings 2024 Network and Distributed System Security Symposium. San Diego, CA, USA: Internet Society, 2024. [...

    2024

  46. [54]

    Physical-layer Identification of RFID Devices

    B. Danev and T. S. Heydt-Benjamin, “Physical-layer Identification of RFID Devices.”

  47. [55]

    Hold the Door! Fingerprinting Your Car Key to Prevent Keyless Entry Car Theft,

    K. Joo, W. Choi, and D. H. Lee, “Hold the Door! Fingerprinting Your Car Key to Prevent Keyless Entry Car Theft,” Mar. 2020. [Online]. Available: http://arxiv.org/abs/2003.13251

    2020 arXiv

  48. [56]

    IoT-ID: A Novel Device-Specific Identifier Based on Unique Hardware Fingerprints,

    G. Vaidya, A. Nambi, T. Prabhakar, V . Kumar T, and S. Sudhakara, “IoT-ID: A Novel Device-Specific Identifier Based on Unique Hardware Fingerprints,” in 2020 IEEE/ACM Fifth International Conference on Internet-of-Things Design and Implementation (IoTDI) , Apr. 2020, pp. 189–20...

    2020

  49. [57]

    PUF-Based Authentication and Key Agreement Protocols for IoT, WSNs, and Smart Grids: A Comprehensive Survey,

    P. Mall, R. Amin, A. K. Das, M. T. Leung, and K.-K. R. Choo, “PUF-Based Authentication and Key Agreement Protocols for IoT, WSNs, and Smart Grids: A Comprehensive Survey,” IEEE Internet of Things Journal , vol. 9, no. 11, pp. 8205–8228, Jun. 2022, conference Name: IEEE Interne...

    2022

  50. [58]

    A novel lightweight PUF based authentication protocol for IoT without explicit CRPs in verifier database,

    K. Nimmy, S. Sankaran, and K. Achuthan, “A novel lightweight PUF based authentication protocol for IoT without explicit CRPs in verifier database,” Journal of Ambient Intelligence and Humanized Computing, vol. 14, no. 5, pp. 6227–6242, May 2023. [Online]. Available: https://do...

    2023 doi

  51. [59]

    Role-based access control,

    R. S. Sandhu, “Role-based access control,” in Advances in computers . Elsevier, 1998, vol. 46, pp. 237–286

    1998

  52. [60]

    Towards usage control models: beyond tradi- tional access control,

    J. Park and R. Sandhu, “Towards usage control models: beyond tradi- tional access control,” in Proceedings of the seventh ACM symposium on Access control models and technologies , 2002, pp. 57–64

    2002

  53. [61]

    Speed up compile time in STM32CubeIDE |https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/ speed-up-compile-time-in-stm32cubeide/td-p/295846,

    “Speed up compile time in STM32CubeIDE |https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/ speed-up-compile-time-in-stm32cubeide/td-p/295846,” Apr. 2020, section: STM32 MCUs TouchGFX and GUI. [Online]. Available: https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/ s...

    2020

  54. [62]

    Why and when does multitasking impair flow and subjective performance? a daily diary study on the role of task appraisals and work engagement,

    H. Pluut, M. Darouei, and M. E. L. Zeijen, “Why and when does multitasking impair flow and subjective performance? a daily diary study on the role of task appraisals and work engagement,” Frontiers in Psychology, vol. 15, p. 1384453, 2024

    2024

  55. [63]

    Experimental evidence for the effects of task repetitiveness on mental strain and objective work performance,

    J. A. H ¨ausser, S. Schulz-Hardt, T. Schultze, A. Tomaschek, and A. Mo- jzisch, “Experimental evidence for the effects of task repetitiveness on mental strain and objective work performance,” Journal of Organiza- tional Behavior, vol. 35, no. 5, pp. 705–721, 2014

    2014

  56. [64]

    Gray Release - Well-Architected Framework - Alibaba Cloud Documentation Center https://www.alibabacloud.com/help/en/ well-architected/latest/grayscale

    “Gray Release - Well-Architected Framework - Alibaba Cloud Documentation Center https://www.alibabacloud.com/help/en/ well-architected/latest/grayscale.” [Online]. Available: https://www. alibabacloud.com/help/en/well-architected/latest/grayscale

  57. [65]

    Uptane: Securing Software Updates for Automobiles,

    T. Karthik, D. McCoy, S. Lauzon, A. Brown, S. Awwad, R. Bielawski, C. Mott, A. Weimerskirch, and J. Cappos, “Uptane: Securing Software Updates for Automobiles,” in International Conference on Embedded Security in Car , 2016-11

    2016

  58. [66]

    High-availability computer systems,

    J. Gray and D. Siewiorek, “High-availability computer systems,” Com- puter, vol. 24, no. 9, pp. 39–48, Sep. 1991, conference Name: Computer. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/84898

    1991

  59. [67]

    The Design of High Availability Dynamic Web Server Cluster,

    M. Data, D. P. Kartikasari, and A. Bhawiyuga, “The Design of High Availability Dynamic Web Server Cluster,” in 2019 International Conference on Sustainable Information Engineering and Technology (SIET) , Sep. 2019, pp. 181–186. [Online]. Available: https://ieeexplore.ieee.org/...

    2019

  60. [68]

    AHAS: Improve & Maintain High Availability for Applications - Alibaba Cloud

    “AHAS: Improve & Maintain High Availability for Applications - Alibaba Cloud.” [Online]. Available: https://www.alibabacloud.com/ product/ahas

  61. [69]

    High availability and scalability on AWS - Real-Time Communication on AWS

    “High availability and scalability on AWS - Real-Time Communication on AWS.” [Online]. Available: https://docs. aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/ high-availability-and-scalability-on-aws.html

  62. [70]

    Azure availability zones – High Availability at Scale | Microsoft Azure

    “Azure availability zones – High Availability at Scale | Microsoft Azure.” [Online]. Available: https://azure.microsoft.com/en-us/explore/ global-infrastructure/availability-zones

  63. [71]

    Azure High Availability: Basic Concepts and a Checklist

    Y . P. Manager, Technical Content, “Azure High Availability: Basic Concepts and a Checklist.” [Online]. Available: https://bluexp.netapp. com/blog/azure-high-availability-basic-concepts-and-a-checklist

  64. [72]

    Fully Managed Container Solution – Amazon Elastic Container Service (Amazon ECS) - Amazon Web Services

    “Fully Managed Container Solution – Amazon Elastic Container Service (Amazon ECS) - Amazon Web Services.” [Online]. Available: https://aws.amazon.com/ecs/

  65. [73]

    Elastic Compute Service (ECS): Elastic & Secure Cloud Servers - Alibaba Cloud

    “Elastic Compute Service (ECS): Elastic & Secure Cloud Servers - Alibaba Cloud.” [Online]. Available: https://www.alibabacloud.com/en/ product/ecs? p lc=1 Qian Zhang is currently pursuing the M.S. degree with the College of Com- puter Science and Technology (College of Data Sc...

    2020

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.