Skip to content

Latest commit

 

History

History
114 lines (97 loc) · 9.37 KB

threat-modeling.md

File metadata and controls

114 lines (97 loc) · 9.37 KB

Threat Model Analysis for espressif/esp-idf

Threat: Bypassing Secure Boot

  • Threat: Secure Boot Bypass
  • Description: An attacker with physical access attempts to modify the bootloader or the initial application image to execute arbitrary code. They might use techniques like glitching the power supply during boot, exploiting vulnerabilities in the bootloader's signature verification process, or directly modifying the flash memory if it's not encrypted.
  • Impact: Complete device compromise. The attacker gains full control over the device, bypassing all security measures. They can steal data, install persistent malware, or use the device for malicious purposes.
  • Affected ESP-IDF Component: esp_secure_boot (Secure Boot V2), Bootloader, eFuse controller.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Enable Secure Boot V2 (RSA-PSS or ECDSA) in the ESP-IDF project configuration.
    • Use a strong, unique signing key and protect it rigorously (ideally using an HSM).
    • Enable Flash Encryption (see below) to prevent direct modification of the flash contents.
    • Burn eFuses to permanently disable JTAG debugging and prevent reading the Secure Boot key.
    • Implement anti-rollback protection to prevent downgrading to a vulnerable firmware version.
    • Physically secure the device to limit unauthorized access.

Threat: Flash Encryption Key Compromise

  • Threat: Flash Encryption Key Leakage
  • Description: An attacker gains access to the flash encryption key. This could happen through side-channel attacks (power analysis, timing analysis), exploiting debugging interfaces (if not disabled), or through software vulnerabilities that allow reading the key from memory.
  • Impact: Decryption of the entire flash content. The attacker can extract sensitive data (credentials, proprietary code, user data) and potentially modify the firmware.
  • Affected ESP-IDF Component: esp_flash_encryption, eFuse controller, potentially any component that handles the key in memory.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Enable Flash Encryption in "Release" mode in ESP-IDF. This disables some debugging features that could leak the key.
    • Burn eFuses to prevent reading the key via JTAG or UART.
    • Minimize the time the key is present in RAM.
    • Consider using hardware-assisted key storage if available on the specific ESP32 variant.
    • Protect the device from physical attacks that could allow side-channel analysis.
    • Regularly audit code for potential vulnerabilities that could leak the key.

Threat: NVS Plaintext Data Storage

  • Threat: Unencrypted Sensitive Data in NVS
  • Description: Developers store sensitive data (Wi-Fi credentials, API keys, etc.) in the Non-Volatile Storage (NVS) partition without enabling NVS encryption. An attacker with access to the flash (either physically or through a flash read vulnerability) can read this data.
  • Impact: Exposure of sensitive data, potentially leading to network compromise, unauthorized access to services, or impersonation.
  • Affected ESP-IDF Component: nvs_flash (NVS library).
  • Risk Severity: High
  • Mitigation Strategies:
    • Enable NVS encryption in ESP-IDF.
    • Carefully review all data stored in NVS and ensure that any sensitive information is encrypted.
    • Use strong, randomly generated keys for NVS encryption.

Threat: Network Stack Vulnerabilities

  • Threat: Exploitation of Network Stack Bugs
  • Description: An attacker exploits vulnerabilities in ESP-IDF's network stack (lwIP, TCP/IP implementation, Bluetooth stack) to cause denial-of-service, gain remote code execution, or leak information. This could involve sending malformed packets or exploiting buffer overflows.
  • Impact: Device crash, denial-of-service, potential for remote code execution and complete device compromise.
  • Affected ESP-IDF Component: lwip (TCP/IP stack), esp_netif, esp_wifi, esp_bt (Bluetooth stack), and related network components.
  • Risk Severity: High
  • Mitigation Strategies:
    • Keep ESP-IDF updated to the latest stable release to receive security patches.
    • Perform regular security audits and penetration testing of the network stack.
    • Disable unused network services and protocols to reduce the attack surface.
    • Implement robust input validation and sanitization for all network data received by the device.
    • Use memory-safe coding practices to prevent buffer overflows and other memory corruption vulnerabilities.

Threat: Unsigned OTA Update

  • Threat: Malicious OTA Firmware Injection
  • Description: An attacker uploads a malicious firmware image to the device through the OTA update mechanism. This is possible if the OTA process doesn't properly verify the digital signature of the update image.
  • Impact: Complete device compromise. The attacker can replace the legitimate firmware with their own, gaining full control.
  • Affected ESP-IDF Component: esp_https_ota (HTTPS OTA library), esp_ota_ops (OTA operations), bootloader.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Use ESP-IDF's secure OTA update mechanism, which verifies digital signatures.
    • Protect the OTA signing keys with extreme care (use an HSM).
    • Use HTTPS for downloading OTA updates to prevent man-in-the-middle attacks.
    • Implement rollback protection to prevent downgrading to a vulnerable firmware version.
    • Implement a secure boot process to verify the integrity of the OTA partition before booting.

Threat: Debugging Interface Exploitation

  • Threat: Unauthorized Access via JTAG/UART
  • Description: An attacker with physical access uses the JTAG or UART debugging interfaces to extract firmware, modify memory contents, or gain control of the device.
  • Impact: Complete device compromise, data extraction, potential for reverse engineering.
  • Affected ESP-IDF Component: JTAG interface, UART peripheral, eFuse controller.
  • Risk Severity: High (assuming physical access is possible)
  • Mitigation Strategies:
    • Disable JTAG debugging in production devices by burning the appropriate eFuses.
    • Restrict access to the UART console. Consider requiring authentication or disabling it entirely in production builds.
    • Use a secure bootloader that disables debugging interfaces after the boot process is complete.
    • Physically secure the device to prevent unauthorized access.

Threat: Memory Corruption Bugs

  • Threat: Buffer Overflow / Memory Corruption
  • Description: An attacker exploits a buffer overflow or other memory corruption vulnerability in the application code (or ESP-IDF components) to overwrite memory, potentially leading to arbitrary code execution.
  • Impact: Device crash, denial-of-service, potential for remote code execution and complete device compromise.
  • Affected ESP-IDF Component: Potentially any component written in C/C++. Most likely in application code, but could also be in ESP-IDF components.
  • Risk Severity: High
  • Mitigation Strategies:
    • Use safe string handling functions (e.g., strlcpy, snprintf instead of strcpy, sprintf).
    • Perform rigorous bounds checking on all array and buffer accesses.
    • Use static analysis tools (e.g., clang-tidy, cppcheck) to identify potential memory safety issues.
    • Consider using memory-safe wrappers or libraries where appropriate.
    • Enable stack smashing protection (if supported by the compiler and ESP-IDF).
    • Conduct thorough code reviews, focusing on memory management.

Threat: Bluetooth Pairing Vulnerabilities

  • Threat: Unauthorized Bluetooth Pairing
  • Description: An attacker exploits weaknesses in the Bluetooth pairing process (e.g., using "Just Works" pairing without user confirmation or exploiting vulnerabilities in the pairing protocol) to pair with the device without authorization.
  • Impact: Unauthorized access to the device via Bluetooth, potential for data interception or injection, device control.
  • Affected ESP-IDF Component: esp_bt (Bluetooth stack), specifically the pairing and bonding related APIs (e.g., esp_bt_gap_set_security_param, esp_bt_gap_ssp_confirm_reply).
  • Risk Severity: High
  • Mitigation Strategies:
    • Use Secure Simple Pairing (SSP) with appropriate input/output capabilities (e.g., display for numeric comparison, keyboard for passkey entry) to ensure secure pairing.
    • Implement proper user confirmation mechanisms for pairing requests (e.g., requiring the user to press a button on the device).
    • Avoid using "Just Works" pairing unless absolutely necessary and the device has no other input/output capabilities. If "Just Works" must be used, clearly inform the user about the security implications.
    • Consider using Bluetooth LE Secure Connections for enhanced security.
    • Regularly update the ESP-IDF to the latest version to benefit from security patches related to the Bluetooth stack.