Wireless and radio security in firmware code

Why this area matters

Wi-Fi, Bluetooth Low Energy, Zigbee, Thread and LoRaWAN all have sound security modes — but each lets firmware opt out. A pre-shared key compiled into every unit, BLE "Just Works" pairing on a device that unlocks something, or a network key shipped in source means one extracted image compromises the whole fleet. These map to CWE-798 (hard-coded credentials) and CWE-319/CWE-300 (cleartext and unauthenticated channels).

Generic scanners rarely understand embedded code. A secrets scanner may catch a PSK string, but nothing tells you whether the pairing mode on that device needs MITM protection or whether the constant is a test fixture. A review agent reads the surrounding code and makes that call.

What goes wrong in real applications

• Shared, hard-coded network keys

  A Wi-Fi PSK or network key baked into firmware is the same on every device. Anyone who reads one firmware image can join or decrypt the network of every customer.

• Unauthenticated BLE pairing

  "Just Works" pairing has no protection against a man in the middle. On devices that control locks, payments or health data, a nearby attacker can pair or intercept traffic.

• Legacy or downgraded radio security

  Allowing WEP, WPA/TKIP or BLE legacy pairing for compatibility keeps known-weak modes available, and a device may silently fall back to them.

• Unauthenticated updates over the air

  Firmware that accepts updates over a radio link without checking a signature can be made to install someone else's code.

Sample: the risky pattern and the fix

#define WIFI_SSID "factory-net"
#define WIFI_PSK  "changeme123"   /* same key on every unit */

void radio_init(void) {
    wifi_join(WIFI_SSID, WIFI_PSK);
    ble_set_io_capability(BLE_IO_NO_INPUT_NO_OUTPUT); /* "Just Works" */
    ble_set_mitm_protection(false);
    ble_set_bonding(true);
}

static char wifi_ssid[33];
static char wifi_psk[64];

void radio_init(void) {
    /* Per-device credentials written at provisioning, never in source. */
    secure_store_read("wifi_ssid", wifi_ssid, sizeof(wifi_ssid));
    secure_store_read("wifi_psk", wifi_psk, sizeof(wifi_psk));
    wifi_join(wifi_ssid, wifi_psk);
    ble_set_io_capability(BLE_IO_DISPLAY_YESNO); /* numeric comparison */
    ble_set_secure_connections(true);
    ble_set_mitm_protection(true);
    ble_set_bonding(true);
}

The original compiles one Wi-Fi key into every device and pairs over BLE with no protection against interception. The fix reads per-device credentials from secure storage written at provisioning and requires LE Secure Connections with numeric comparison, so pairing is authenticated. The API names are illustrative; the pattern applies to any vendor SDK.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Hard-coded Wi-Fi PSKs, network keys and default device passwords in firmware source and config headers (Gitleaks plus agent review)
• BLE pairing settings: IO capability, MITM protection, LE Secure Connections, bonding
• Legacy modes enabled for compatibility: WEP, TKIP, legacy pairing
• Over-the-air update code that skips signature verification
• Whether a flagged key is a test fixture or development-board default rather than a production value

Scope and limits

• It doesn't test radios, sniff traffic or scan for networks — it reads the firmware source and configuration in your repository.
• Behavior decided inside a binary vendor SDK or the chipset's ROM isn't visible to a source scan.
• Coverage depends on Semgrep and Gitleaks rules matching your codebase; embedded C has fewer stock rules than web languages, so the review agents see fewer candidates here.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.
• Cryptography — Checks that cryptographic primitives fit their purpose and keys, IVs and randomness are handled correctly.
• Network & transport security — Checks that data in transit is encrypted and certificates are actually verified.