菜单
Use when designing firmware update mechanisms for IoT devices — implementing code signing, secure boot chains, and rollback protection to prevent malicious firmware from running on deployed hardware.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/jeffreytse/grimoire-core --skill design-iot-secure-boot命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use when comparing very differently-titled roles for compensation banding, leveling, or organizational design — score each role's inherent Know-How (knowledge, skills, experience required), Problem Solving (complexity and freedom of thinking, scored as a percentage of Know-How), and Accountability (freedom to act and magnitude of impact), because job titles and informal seniority perceptions vary inconsistently across departments and don't provide a comparable basis on their own.
Use when many people request your scarce time, mentorship, or expertise and you cannot evaluate their genuine commitment level from a conversation alone — require a specific, costly, objectively verifiable unit of self-directed output (a set number of completed attempts) before engaging, because genuine commitment is what a conversation cannot reliably reveal but a completed, verifiable body of work can.
Use when deciding how to allocate a manager's or leader's limited time across competing activities — before defaulting to whatever is most urgent, estimate each candidate activity's leverage (how many people's output it affects, for how long, and whether it requires your specific position), because a manager's actual output is the output of the organization under their influence, not their own individual task completion.
基于 SOC 职业分类
正在显示 SKILL.md
| name | design-iot-secure-boot |
| description | Use when designing firmware update mechanisms for IoT devices — implementing code signing, secure boot chains, and rollback protection to prevent malicious firmware from running on deployed hardware. |
| source | OWASP IoT Top 10 I4 (owasp.org/www-project-internet-of-things/); NIST SP 800-193 (Platform Firmware Resiliency); IETF SUIT manifest standard (RFC 9019); Arm TrustZone secure boot documentation |
| tags | ["security","owasp","iot","firmware","secure-boot","code-signing","embedded","hardware"] |
Implement cryptographic code signing for firmware, verified boot chain from ROM to application, and rollback prevention — ensuring only authorized firmware runs on IoT devices even after physical access.
Adopted by: OWASP IoT Top 10 I4 (Lack of Secure Update Mechanism). NIST SP 800-193 (Platform Firmware Resiliency) is the US federal standard for firmware integrity. The IETF SUIT (Software Updates for Internet of Things) manifest standard (RFC 9019) defines the protocol. Arm TrustZone secure boot is implemented in the majority of modern IoT SoCs (STM32H5, NXP i.MX RT, Nordic nRF9161). AWS IoT Jobs, Azure Device Update, and Mbed TLS all implement SUIT-compatible update pipelines. Impact: Mirai botnet (2016, 600,000+ devices compromised) and its variants exploited devices with no firmware verification — malicious firmware was flashed over default credentials and telnet. VPNFilter (2018, 500,000 routers compromised) survived factory resets because it persisted in flash memory beyond the OS partition. NIST SP 800-193 states that "the ability to detect and recover from corrupt or maliciously modified firmware is a foundational security control" — without it, physical access equals full device compromise. Why best: OTA updates without signature verification allow any attacker who intercepts the update channel (or the update server itself) to push malicious firmware to the entire device fleet. Code signing ensures the device verifies the firmware author before executing it. Secure boot ties the trust chain to hardware (ROM key, OTP fuses) so no software-level attack can bypass it.
Sources: OWASP IoT Top 10 I4; NIST SP 800-193; IETF RFC 9019 (SUIT Manifest); Arm Platform Security Architecture (PSA) documentation
Sign firmware images before distribution:
# Generate signing key (keep private key in HSM for production)
openssl ecparam -name prime256v1 -genkey -noout -out firmware-signing-key.pem
openssl ec -in firmware-signing-key.pem -pubout -out firmware-signing-key-pub.pem
# Sign firmware binary
openssl dgst -sha256 -sign firmware-signing-key.pem \
-out firmware-v1.2.3.bin.sig firmware-v1.2.3.bin
# Verify (device does this)
openssl dgst -sha256 -verify firmware-signing-key-pub.pem \
-signature firmware-v1.2.3.bin.sig firmware-v1.2.3.bin
Implement ECDSA signature verification in the bootloader:
#include "mbedtls/ecdsa.h"
#include "mbedtls/sha256.h"
/* Public key burned into OTP fuses or stored in secure storage */
static const uint8_t SIGNING_PUBLIC_KEY[] = {
0x04, /* uncompressed point marker */
/* 64-byte public key X and Y coordinates */
};
int verify_firmware(const uint8_t *firmware, size_t firmware_len,
const uint8_t *signature, size_t sig_len) {
uint8_t hash[32];
mbedtls_sha256(firmware, firmware_len, hash, 0);
mbedtls_ecdsa_context ecdsa;
mbedtls_ecdsa_init(&ecdsa);
int ret = mbedtls_ecp_point_read_binary(
&ecdsa.private_grp, &ecdsa.private_Q,
SIGNING_PUBLIC_KEY, sizeof(SIGNING_PUBLIC_KEY)
);
if (ret != 0) return VERIFY_FAILED;
ret = mbedtls_ecdsa_read_signature(&ecdsa, hash, (hash),
signature, sig_len);
mbedtls_ecdsa_free(&ecdsa);
(ret == ) ? VERIFY_OK : VERIFY_FAILED;
}
Implement rollback protection using a monotonic counter:
/* Store anti-rollback counter in OTP fuses — cannot be decremented */
typedef struct {
uint32_t version; /* firmware semantic version */
uint32_t anti_rollback; /* must be >= current OTP counter */
} FirmwareHeader;
int check_rollback(const FirmwareHeader *header) {
uint32_t otp_counter = read_otp_anti_rollback_counter();
/* New firmware must have counter >= current value */
if (header->anti_rollback < otp_counter) {
return ROLLBACK_DETECTED; /* reject downgrade */
}
/* After successful boot, advance OTP counter to new firmware's value */
if (header->anti_rollback > otp_counter) {
/* Only write OTP after successful boot, not at verification time */
schedule_otp_update(header->anti_rollback);
}
return ROLLBACK_OK;
}
Implement A/B partition update with revert capability:
/* Dual-bank flash layout:
* Bank A: active firmware (currently running)
* Bank B: update target (download here before activating)
*/
typedef enum { BANK_A = 0, BANK_B = 1 } FlashBank;
UpdateResult apply_update(const uint8_t *firmware, size_t len,
const uint8_t *signature, size_t sig_len) {
/* Step 1: verify before touching active partition */
if (verify_firmware(firmware, len, signature, sig_len) != VERIFY_OK) {
return UPDATE_SIGNATURE_INVALID;
}
FlashBank inactive = get_inactive_bank();
/* Step 2: erase and write to inactive bank only */
flash_erase_bank(inactive);
flash_write(get_bank_address(inactive), firmware, len);
/* Step 3: verify what was written */
if (!verify_bank_contents(inactive, firmware, len)) {
return UPDATE_WRITE_ERROR;
}
/* Step 4: set boot flag — reverts to A if B fails to boot 3 times */
set_pending_boot_bank(inactive, max_boot_attempts=3);
return UPDATE_PENDING_REBOOT;
}
OTA update client with transport security:
/* Use TLS 1.2+ with certificate pinning for update server */
#include "mbedtls/ssl.h"
#define UPDATE_SERVER_CERT_FINGERPRINT \
"\xAB\xCD\xEF..." /* SHA-256 of server certificate */
int download_update(const char *url, uint8_t *buffer, size_t *len) {
/* Pin server certificate — prevent MitM from serving malicious firmware */
ssl_config.verify_mode = MBEDTLS_SSL_VERIFY_REQUIRED;
ssl_config.ca_chain = &server_cert_chain;
/* Verify fingerprint after TLS handshake */
const mbedtls_x509_crt *peer_cert = mbedtls_ssl_get_peer_cert(&ssl);
uint8_t fingerprint[32];
mbedtls_sha256(peer_cert->raw.p, peer_cert->raw.len, fingerprint, 0);
if (memcmp(fingerprint, UPDATE_SERVER_CERT_FINGERPRINT, 32) != 0) {
return ERROR_CERT_MISMATCH;
}
/* ... download proceeds ... */
}