This shows you the differences between two versions of the page.
|
iothings:laboratoare:2025:lab10 [2025/12/06 21:35] dan.tudose |
iothings:laboratoare:2025:lab10 [2025/12/06 21:35] (current) dan.tudose |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| Designing OTA for embedded systems also introduces engineering trade-offs that are less visible in traditional software. Devices must update safely despite limited flash, intermittent connectivity, and the risk of power loss mid-installation. A robust OTA approach typically uses separate firmware slots so a known-good image remains available if an update fails. Just as importantly, OTA is part of a security boundary: update mechanisms must ensure that only authentic, intact firmware can be installed, or they can become a high-impact attack path in an IoT fleet. | Designing OTA for embedded systems also introduces engineering trade-offs that are less visible in traditional software. Devices must update safely despite limited flash, intermittent connectivity, and the risk of power loss mid-installation. A robust OTA approach typically uses separate firmware slots so a known-good image remains available if an update fails. Just as importantly, OTA is part of a security boundary: update mechanisms must ensure that only authentic, intact firmware can be installed, or they can become a high-impact attack path in an IoT fleet. | ||
| + | {{ :iothings:laboratoare:2025:ota1.jpg?800 |}} | ||
| ====== Simple OTA ====== | ====== Simple OTA ====== | ||
| Line 17: | Line 18: | ||
| * document basic threat-model thinking. | * document basic threat-model thinking. | ||
| - | {{ :iothings:laboratoare:2025:ota1.jpg?800 |}} | ||
| ===== Learning outcomes ===== | ===== Learning outcomes ===== | ||