Skip to content
42dot

Sr. Staff Firmware Engineer (Secure Boot & OTA implementation)

Sunnyvale, United StatesUnited States
Staff · FullTime · ENGINEERING
POSTED 19 JUNVERIFIED 54M AGO
Apply Ask
Pay · 42dot
$199k–$257k
p25–p75 · n=7
Open for
137d
since 19 Jun
H-1B · FY26
2
certified LCAs
Hiring · 30d
106
−3 net · open roles

We are looking for the best

About Us

42dot is a mobility AI company committed to solving mobility challenges with software and AI. As the Global Software Center of Hyundai Motor Group, 42dot pioneers the future of mobility by advancing the development of software-defined vehicles.

We develop safety-first, user-centric software-defined vehicle technologies that deliver the latest performance through continuous updates like smartphones. By advancing software and AI technology, 42dot envisions a world where everything is connected and moves autonomously through a self-managing urban transportation operating system.

About the Role

As a Sr. Staff Firmware Engineer, you will build the two components everything else on the platform depends on: the multi-stage secure boot chain and the Uptane update client. The platform is a greenfield, ASIL-D safety firmware platform (ISO 26262 Safety Element out of Context) for a microzonal vehicle E/E architecture, running on NXP S32K3-class lockstep MCUs with a hardware security engine. JTAG is used once per board — to bring up the silicon and flash the immutable bootloader — and every deployment after that, including continuous integration, goes through Uptane. Until your code works, nothing ships; once it works, every engineer on the program runs it daily.

You implement to a security architecture owned by the platform's Firmware Security Architect and to the platform's ASIL-D rules: MISRA C, zero-deviation static analysis, static memory, requirements-based test with MC/DC coverage, and full traceability. Requirement sets for the immutable bootloader, the mutable bootloader and the update client already exist; you inherit, complete and implement them. You are the hands — and you are expected to push back when the hardware or the timing says the architecture is wrong.

Responsibilities

Secure Boot-Chain Implementation: Write and own the multi-stage boot sequence on the target MCU — startup code, linker command files and memory maps, flash drivers, hardware security engine integration (key catalogs, secure-boot configuration, signature-verification services), anti-rollback counters in HSE-protected storage or OTP, and recovery and fail-safe boot — with boot time measured against budget.

Fail-Safe A/B Update Layouts: Implement atomic A/B firmware-slot and dual-bank schemes: the low-level state machines for partition switching, background flashing, verify-before-activate and automatic runtime fallback.

Uptane Client: Implement the on-device update client — metadata parsing and signature/threshold verification across the Root, Timestamp, Snapshot and Targets roles in constrained, statically allocated C; image transfer from the Primary over the platform's Ethernet middleware; staging to flash; the install → verify → activate → confirm/rollback state machine; delta application; and ECU version reporting — as an ASIL-D mandatory application under the platform's lifecycle manager. [SCOPE DECISION: the partial-verification Secondary is core scope; include the full-verification Primary client on the vehicle's central compute only if it stays in this team.]

Hardware-Enforced Isolation: Configure resource-domain controllers (NXP XRDC-class domain IDs, MDAC, PAC) and core MPUs across boot stages and the handoff to the application, to the isolation policy set by the Security Architect, and validate the resulting memory protections and security states in the lab.

Bandwidth & Storage Optimization: Implement delta application and compression-aware flash budgeting on embedded MCU flash to minimize bus bandwidth and program/erase cycles.

Diagnostic Reprogramming: Implement the diagnostic reprogramming entry (security access, transfer services) where OEM service processes require it, on the platform's transport, without importing an AUTOSAR diagnostic stack.

Defensive Engineering: Harden the verification path against voltage and clock glitching, fault injection and side channels — redundant checks, constant-time comparisons, fail-closed defaults — and feed findings back into the threat model.

Source · 42dotFirst seen 2 NovOriginal ↗