Sr. Staff Firmware Security Architect (Domain Security — Secure Boot, OTA & Vehicle Cybersecurity)

Role details

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 Security Architect, you will own the security architecture of our next-generation Software-Defined Vehicle (SDV) real-time platform end to end: the secure boot chain, the Uptane-based over-the-air update trust model, vehicle-lifecycle key management, secure diagnostics and debug, and the ISO/SAE 21434 work products that carry all of it through UNECE R155/R156 type approval. This is a builder's architect role: you decide what the boot chain and update client must do, prove it is enough, hold review authority over the engineers who implement it, and defend the design to OEM security engineers and third-party assessors. Responsibilities - Chain-of-Trust Architecture: Define the multi-stage secure boot sequence — boot ROM handoff, immutable and mutable bootloader stages, signature verification anchored in the hardware security engine, anti-rollback, A/B activation, recovery and fail-safe boot policy — with boot-time budgets that respect the platform's safety timing. - Uptane Trust Model: Own the on-device Uptane security design: the online Director and offline-keyed Image repositories, metadata and role structure (Root, Timestamp, Snapshot, Targets), signature thresholds and key rotation, full-verification Primary versus partial-verification Secondary policy, and defenses against rollback, freeze, replay and mix-and-match attacks — for field campaigns and for the platform's own CI/CD path. - Hardware Root of Trust & Key Management: Specify the key hierarchy, secure key storage and device attestation, end-of-line provisioning, secure debug lock/unlock and RMA re-provisioning, revocation and rotation, and the signing infrastructure and key-ceremony requirements the release process must follow. - Cryptographic Policy: Own algorithm selection, key sizes and crypto-agility, including a post-quantum migration path for firmware signing across a vehicle's service life. - Cloud & Fleet Interfaces: Author the platform's Uptane deployment profile (POUF) and co-design the edge-to-cloud interfaces with the Cloud/Infrastructure team: secure time attestation for Secondaries without a trusted clock, vehicle version manifests, and campaign and bundle integrity rules. - Isolation & Defensive Engineering: Define the hardware-enforced isolation policy (resource-domain and MPU partitioning) between boot stages, security services and application code, and the threat model and countermeasure requirements for physical and electrical attack vectors — voltage and clock glitching, fault injection and side channels. - Secure Diagnostics & Communication: Define security-access and reprogramming policy for the diagnostic path where OEM service processes require it, and the authentication and freshness scheme for safety-relevant traffic on the in-vehicle network and middleware. - ISO/SAE 21434 & Regulation: Author the platform TARA, cybersecurity concept and cybersecurity case; determine CALs; produce the evidence the OEM's CSMS (UNECE R155) and SUMS (UNECE R156, ISO 24089) processes require from the platform; ensure compliance with OEM HSM and key-management specifications. - Safety–Security Co-Engineering: Work with the platform safety lead so that security mechanisms — all ASIL-D code on this platform — carry their own safety analysis (freedom from interference, WCET, fault handling), and the safety case and the cybersecurity case never contradict each other. - Review Authority: Write testable security requirements into the platform's traceability system, review boot-chain and update-client implementation against them at code level, scope and adjudicate penetration tests, and gate release. - Vulnerability Response & Suppliers: Stand up the platform's vulnerability-handling and PSIRT interface for the product's field life, and own the security requirements flowed to suppliers building on the platform. Qualifications - Tenure: 15+ years in embedded or firmware engineering, at least 6 of them owning embedded or product security. - Chain-of-Trust Ownership: Personal ownership of a production secure-boot or chain-of-trust design on MCU-class silicon (bare-metal or RTOS; not Linux-only). Assessment, penetration-test or research exposure alone does not meet this bar. - Applied Cryptography: Practitioner-level command of signature schemes and their failure modes, key hierarchies, HSM/secure-element programming (NXP HSE/CSEc/SHE+, Infineon AURIX HSM or EVITA-class equivalents), and manufacturing key provisioning. - Update Security: Hands-on with TUF/Uptane trust models or an equivalent signed-metadata update system; have designed or formally reviewed a production update path, including rollback protection. - ISO/SAE 21434 Authorship: Have written a TARA, cybersecurity concept or cybersecurity case and answered an assessor's or OEM's questions on it — not sat adjacent to someone who did. Working familiarity with UNECE R155/R156. - Code-Level Depth: Enough C to review boot and update code, linker scripts, memory maps and HSM API usage unaided, and to tell an implementer precisely what is wrong. - Technical Writing: Testable requirements, decisions with recorded rationale, and evidence a third party can audit. Preferred Qualifications - Uptane by Name: Standards participation (IEEE-ISTO 6100), workshop or community involvement, or TUF / python-tuf / go-tuf contributions. - Functional