Secure Boot Processes

Bootloader and Security in ECU the bootloader is a critical gatekeeper in automotive cybersecurity. --- Key Security Features in the Bootloader 1. Authentication of Flash Requests Ensures only authorized tools can flash firmware Uses challenge–response mechanism (e.g., in UDS Service 0x27 – SecurityAccess) Bootloader gives a challenge (seed) → Tool responds with key Bootloader compares with internally stored secret → Grants or denies access Prevents unauthorized users from flashing the ECU --- 2. Secure Boot Verifies that the application firmware has not been tampered with Bootloader checks digital signature or hash (e.g., SHA256) of the firmware Signature is verified using public key (stored in ROM or OTP) If verification fails → Do not boot application Ensures only trusted and authentic firmware runs --- 3. Firmware Encryption Prevents firmware reverse engineering Firmware binary is encrypted (e.g., AES) Bootloader decrypts it on-the-fly while flashing If attacker reads Flash memory, they see only encrypted junk --- 4. Read/Write Protection Prevents memory dumping or rewriting without permission Bootloader enforces read protection on Flash May use microcontroller hardware protection features Flash blocks are set to read-only or write-once Prevents code cloning or IP theft --- 5. Secure Firmware Update (FOTA/UDS) Securely updates ECU over-the-air or via diagnostic tools Bootloader uses secure transport protocols: UDS over CAN (with security access) TLS over IP (for Ethernet/FOTA) Can verify update origin, version, and authenticity Prevents "man-in-the-middle" attacks and downgrade attacks --- Security Feature Purpose Security Access (0x27) Restricts flashing to authorized tools Secure Boot Verifies firmware integrity & authenticity Firmware Encryption Prevents reverse engineering Flash Read Protection Prevents cloning & tampering Secure Firmware Update Protects update process from attackers ------- Real-Life Example 1.ECU Bootloader Security Guard at a Secure Facility 2.Checks ID before entry Security access challenge-response 3.Verifies badge authenticity Digital signature verification (Secure Boot) 4.Denies fake credentials Rejects invalid firmware 5.Allows entry if valid Jumps to application

ESP32-based IoT devices are often deployed in physically accessible, network-connected, and long-lived environments. These characteristics make them attractive targets for attackers seeking persistent access, device cloning, or data exfiltration. Unlike traditional IT systems, embedded devices cannot rely on perimeter defenses alone. Security must be built into the firmware, boot process, and hardware configuration from the first instruction executed. This article presents practical, field-tested defense strategies for securing ESP32-based embedded systems using ESP-IDF. The focus is not on abstract security theory, but on concrete mechanisms available in real ESP32 silicon: secure boot, flash encryption, eFuses, TLS, and secure OTA workflows. Each section explains what problem the mechanism solves, why it matters, and how to implement it correctly. #learningbytutorials #esp32 #esp32projects #espidf #embeddedsystems #embeddedprogramming

Understanding Cybersecurity in Embedded Systems: Part 3 – How DIGITAL SIGNATURE is created? Once secure boot ensures that only trusted firmware runs, the next question is: how do we make sure the firmware itself is genuine? That’s where digital signatures come in. What is a Digital Signature? A Digital Signature is like a "tamper-proof seal" for firmware. It proves two things: -The firmware came from the original, trusted manufacturer. -The firmware hasn’t been altered in any way. How a DIGITAL SIGNATURE is created and stored (at the manufacturer’s end): 1)HASH the firmware Think of a HASH like a fingerprint. The firmware image is passed through a Hashing algorithm, such as SHA-256, which generates a fixed-length 256-bit “fingerprint” for the firmware. Even a single-bit change in the firmware will produce a completely different HASH. This ensures that any tampering can be detected. 2)Encrypt the HASH with a key The HASH is then encrypted using an encryption algorithm. Common algorithms include AES-128, RSA, or ECC (The Encryption Algorithms can be symmetric and asymmetric w.r.t keys. I will discuss it in upcoming posts). This encrypted HASH becomes the DIGITAL SIGNATURE. 3)Attach the signature to the firmware The Digital Signature is added to the firmware binary, creating the final firmware image. This combination is what the device receives during boot or when performing a firmware update. ------------------------------------------------------------------------------------- How the device verifies it (at the bootloader end): -The bootloader reads the firmware and its attached signature from flash. -It recalculates the firmware hash using the same algorithm (e.g., SHA-256). -It decrypts the signature using the corresponding decryption method and compares it to the calculated hash. -If the hashes match, the firmware is genuine. -If they don’t match, the device halts or rejects the update. This way, the digital signature helps to authenticate the firmware and ensures that only trusted, unaltered firmware can run on the device.

You arrive at the office and discover that your embedded systems are loading a tampered kernel: the entire fleet is compromised from the very first boot. Some embedded systems are physically exposed and can be manipulated by malicious actors. That’s why it’s critical to protect the device both mechanically and in software. Secure Boot is a fundamental security mechanism based on a chain of trust. In practice, it relies on a Root of Trust burned into the OTP eFuses. At startup, the ROM loads the signed First Stage Bootloader (FSBL) and reads its X.509 certificate containing the public key. It compares the hash of this public key against the one stored in OTP to confirm it matches. Then, it verifies the authenticity of the certificate itself and checks the FSBL’s integrity by validating its hash/signature. If any of these steps fail, the boot process halts. Only if all succeed does the FSBL execute. The FSBL then extends the chain by verifying the next bootloader, which in turn verifies the Linux kernel, and so on up to the initramfs. Each stage authenticates the next, ensuring that only trusted code can run. Of course, this is just an overview, the actual implementation is highly board-specific

Learning of the Day!!! Automotive Software -Secure Boot-Overview 👉 How do we ensure the software controlling the brakes, engine, airbags hasn’t been tampered with? and ❓what if the hacker modified the firmware of the brake ECU?   If the car blindly trusted its firmware, the consequences could be catastrophic.🚓 So before running any software, the ECU asks a simple but powerful question: “Is this firmware genuinely from the manufacturer and untouched?” This is exactly what Secure Boot ensures. 👉Secure Boot ensure that only authenticated and trusted software (SW), signed by a trusted party, can be executed as a boot stage in the device ❓ WHY Do we need Secure Boot? 1.Prevents entry of malicious software into ECU 2.Ensuring software integrity and Authenticity 3.Protecting safety critical ECU's 4.Defending against cyber attacks 🤷♂️🤔what Exactly It does and How it Works?   Secure Boot is a verification process inside every critical automotive ECU. It ensures the ECU boots only manufacturer‑approved firmware by:   🔑 1. Checking the firmware’s DIGITAL SIGNATURE(cryptographic authentication mechanism used to ensure firmware authenticity and integrity)   🧱 2. Using a hardware Root of Trust (Boot ROM) which cannot be modified by hackers 🔐 3. Verifying the signature using keys stored in secure hardware (HSM/SHE) keys are protected in a secure vault by Hardware Security Module(HSM)or Secure Hardware Extension(SHE)   🚫 4. Blocking startup if the software fails validation when Car Starts-ECU's power on and prepares to load its firmware 1️⃣ Bootloader protected BOOT ROM starts 2️⃣ Firmware is read from the flash but not executed 3️⃣Bootloader verifies the digital signature using the public keys stored in HSM 4️⃣If the signature is valid -->ECU continues to boot normally if the signature is invalid or modified -->ECU enters fail-safe mode .   Secure Boot isn’t just a mechanism — it’s a safety foundation for every modern vehicle. It ensures trust at the very first moment your car powers on, protecting drivers, passengers, and the entire driving ecosystem.   #SecureBoot #AutomotiveCybersecurity #CybersecurityBasics #ConnectedCar #AutomotiveSecurity #ECUSecurity #VehicleSafety  

Let's discuss SBSFU: Securer Boot & Secure Firmware Update - The X-CUBE-SBSFU Secure Boot and Secure Firmware Update solution allows the update of the STM32 microcontroller built-in program with new firmware versions, adding new features and correcting potential issues. The update process is performed in a secure way to prevent unauthorized updates and access to confidential on-device data. - The Secure Boot (Root of Trust services) is an immutable code, always executed after a system reset, that checks STM32 static protections, activates STM32 run-time protections and then verifies the authenticity and integrity of user application code before every execution in order to ensure that invalid or malicious code cannot be run. - The Secure Firmware Update application receives the firmware image via a UART interface with the Ymodem protocol, checks its authenticity, and checks the integrity of the code before installing it. The firmware update is done on the complete firmware image, or only on a portion of the firmware image. Examples are provided for single firmware image configuration in order to maximize firmware image size, and for dual firmware image configurations in order to ensure safe image installation and enable over-the-air firmware update capability commonly used in IoT devices. Examples can be configured to use asymmetric or symmetric cryptographic schemes with or without firmware encryption. - The secure key management services provide cryptographic services to the user application through the PKCS #11 APIs (KEY ID-based APIs) that are executed inside a protected and isolated environment. User application keys are stored in the protected and isolated environment for their secured update: authenticity check, data decryption and data integrity check. This is available on the STM32L4 Series with example provided on the B-L475E-IOT01A and B-L4S5I-IOT01A boards. - STSAFE-A110 is a tamper-resistant secure element (HW Common Criteria EAL5+ certified) used to host X509 certificates and keys, and perform verifications that are used for firmware image authentication during Secure Boot and Secure Firmware Update procedures. This is available on the STM32L4 Series with example provided on the B-L4S5I-IOT01A board. - X-CUBE-SBSFU is built on top of STM32Cube software technology, making the portability across different STM32 microcontrollers easy. It is provided as reference code to demonstrate best use of STM32 security protections. The X-CUBE-SBSFU Expansion Package comes with examples running on the STM32L4 Series, STM32F4 Series, STM32F7 Series, STM32G0 Series, STM32G4 Series, STM32H7 Series, STM32L0 Series, STM32L1 Series, and STM32WB Series. An example combining STM32 microcontroller and STSAFE-A100 is also provided for the STM32L4 Series. More details about X-CUCUBE-SBSFU here: https://lnkd.in/gERRmBib

In my discussions with various people about security issues in verified boot, one recurring blind spot keeps coming up: downgrade attacks. 🥾 What is a downgrade attack in the context of a bootloader? It's when an attacker reinstalls an older, properly signed, but known to be vulnerable, bootloader version to exploit previously fixed security flaws. This means just upgrading your bootloader isn’t enough. You need a mechanism to ensure that once a newer version is installed, older versions can never be reinstated. 🥾 How can you prevent downgrade attacks? It depends on your hardware, but common approaches include: 👉 Revocation lists at Boot ROM level: These track revoked versions, but often don’t scale well due to limited key slots. 👉 Hardware Monotonic Counters: A counter increments with every upgrade, and the bootloader checks that its version meets or exceeds the counter. If it doesn’t, execution stops immediately. 🥾 Protecting IoT devices from such attacks is crucial. If you're working on secure boot implementations and want to dive deeper into mitigation strategies, feel free to reach out!