The posting
Contexte de la mission
Steepulse (Grenoble) développe des produits Linux embarqués connectés (Yocto/U-Boot/Mender) sur carte i.MX8MQ. Le stage vise à fermer les derniers vecteurs d'attaque physique (SDP, JTAG) en portant le Secure Boot matériel HAB — déjà déployé sur un produit Android — vers la chaîne Yocto de production, et à préparer la mise en conformité du produit avec le Cyber Resilience Act (analyse d'écart, plan priorisé, premières briques techniques).
- Entreprise : Steepulse
- Début souhaité : janvier 2027
- Durée : 4 à 6 mois
- Lieu : Grenoble
- Niveau visé : cycle ingénieur ou Master en cybersécurité (spécialité sécurité des systèmes embarqués, sécurité matérielle, ou sécurité logicielle et conformité)
Missions principales
1. Contexte
Steepulse conçoit et maintient des produits Linux embarqués connectés, construits avec Debian et mis à jour à distance via Mender. Le bootloader de production de la carte Boundary Devices Nitrogen8M (SoC NXP i.MX8MQ) est customisé en interne.
Le stage couvre deux volets complémentaires : fermer les vecteurs d'attaque par accès physique restants, puis préparer la conformité réglementaire du produit au Cyber Resilience Act.
Volet A — vecteurs d'attaque physiques ouverts
Le bootloader de production a déjà fait l'objet d'un durcissement logiciel au niveau d'U-Boot. Deux vecteurs d'attaque par accès physique ne peuvent pas être fermés au niveau logiciel et restent ouverts :
- Serial Download Protocol (SDP) via les boot mode pins. La ROM de boot du i.MX8MQ supporte le SDP. Un attaquant disposant d'un accès physique au bouton de boot peut forcer ce mode et charger un firmware arbitraire. Le durcissement U-Boot est alors totalement contourné, puisque la ROM s'exécute avant U-Boot.
- Port de débogage JTAG, qui permet de prendre le contrôle du SoC.
La seule façon de fermer durablement ces vecteurs est d'activer la chaîne de confiance matérielle du SoC : HAB (High Assurance Boot), en programmant (« brûlant ») les eFuses du i.MX8MQ. HAB vérifie cryptographiquement la signature de chaque image de boot dès la ROM, permet de désactiver le JTAG et de verrouiller le SoC en configuration « closed ».
Point de départ : Steepulse a déjà implémenté HAB sur le même SoC i.MX8MQ dans le cadre d'un produit Android sur cette même carte. Le stage ne part pas de zéro. Il s'agit de porter cette chaîne de confiance, aujourd'hui appliquée à l'image de boot Android, vers le conteneur de boot du produit Yocto/U-Boot/Mender, puis de la valider et de l'industrialiser.
Volet B — Cyber Resilience Act
Le règlement (UE) 2024/2847 (Cyber Resilience Act, CRA) impose des exigences de cybersécurité à tout fabricant mettant sur le marché européen un produit comportant des éléments numériques. Le calendrier est déjà engagé :
11 septembre 2026 : obligations de signalement applicables. Toute vulnérabilité activement exploitée ou tout incident grave doit faire l'objet d'une alerte auprès de l'ENISA et du CSIRT national sous 24 h, puis d'une notification complète sous 72 h. Cette obligation couvre les produits déjà mis sur le marché.
11 décembre 2027 : application de l'ensemble des exigences produit, marquage CE, exigences essentielles de l'Annexe I (parties I et II), documentation technique, période de support.
Les produits de Steepulse entrent dans le périmètre. L'écart entre l'état actuel du produit et les exigences de l'Annexe I n'a pas encore été mesuré ; le plan de mise en conformité reste à construire.
2. Objectif du stage
Porter le Secure Boot HAB existant (produit Android) vers le bootloader Yocto/U-Boot de la Nitrogen8M, le valider, et fermer les vecteurs d'attaque résiduels (SDP/uuu et JTAG), en préservant un mécanisme de récupération maîtrisé et la compatibilité avec la chaîne Mender.
Analyser le CRA, produire une analyse d'écart argumentée sur le produit, construire un plan de mise en conformité priorisé, et engager le développement des briques techniques manquantes.
Contrainte forte du volet A : sécuriser le produit sans rendre une carte définitivement non récupérable. Le passage en mode closed est irréversible ; la validation en mode open et la stratégie de récupération sont donc traitées avant tout verrouillage.
Cadrage explicite du volet B : le périmètre CRA est probablement trop large pour être achevé dans la durée du stage. Les livrables attendus sont l'analyse d'écart, le plan, et l'implémentation de deux à trois briques prioritaires. Le reste sera repris par l'équipe.
3. Missions détaillées
Volet A — Secure Boot HAB (≈ 3 mois)
Phase 1 — Appropriation et différentiel Android → Yocto (≈ 2 semaines)
Prise en main de la carte, de la chaîne Yocto/dunfell et du système de build des bootloaders.
Étude de l'architecture de boot du i.MX8MQ : ROM, conteneur imx-boot (SPL + U-Boot + ARM Trusted Firmware).
Analyse de la chaîne HAB Android existante et identification de ce qui est réutilisable tel quel.
Différentiel clé : layout du conteneur imx-boot (SPL + ATF) vs image de boot Android, et impact sur la structure du CSF (offsets et plages à signer).
Phase 2 — Port de la signature vers imx-boot (≈ 3 à 4 semaines)
Réutilisation de la PKI et du CST existants ; adaptation du CSF au conteneur imx-boot du produit.
Production d'une image imx-boot signée HAB.
Intégration de la signature dans le build : automatisation dans le flux Yocto.
Phase 3 — Validation en mode « open » (≈ 3 à 4 semaines)
Programmation de l'empreinte SRK (SRKHASH) dans les eFuses, SoC en mode open (HAB actif mais non bloquant).
Vérification de HAB via habstatus dans U-Boot : objectif « no error / no warning » sur les variantes signées.
Tests de non-régression : flash, mise à jour A/B.
Mise en place de la stratégie de récupération maîtrisée post-fermeture (image uuu de secours signée, procédure de re-flash usine).
Phase 4 — Fermeture du SoC et durcissement final (≈ 2 semaines)
Définition de la procédure de passage en mode closed (irréversible) et des critères de validation à respecter avant de brûler le bit de fermeture.
Désactivation du JTAG via eFuses.
Validation sur un lot de cartes de test : une image correctement signée doit démarrer ; une image non signée ou altérée doit être rejetée par la ROM.
Phase 5 — Documentation du volet A (≈ 1 semaine)
Procédure de provisioning usine (programmation des eFuses, signature, flash).
Chaîne HAB documentée (différences Android vs Yocto).
Mise à jour de la section « Security hardening » de la documentation du projet.
Volet B — Cyber Resilience Act (≈ 1 à 3 mois selon la durée du stage)
Phase 6 — Qualification réglementaire et analyse d'écart (≈ 3 à 4 semaines)
Étude du règlement (UE) 2024/2847 : champ d'application, rôle de fabricant, exigences essentielles de l'Annexe I partie I (propriétés de sécurité du produit) et partie II (traitement des vulnérabilités), Annexe II (informations utilisateur), procédures d'évaluation de la conformité.
Qualification du produit : produit par défaut, produit important classe I ou II, produit critique. Conséquence directe sur la procédure d'évaluation applicable (auto-évaluation ou intervention d'un organisme notifié). La qualification doit être argumentée par écrit, fonction par fonction.
Analyse d'écart : matrice exigence / état actuel du produit / écart / charge estimée / priorité. Le volet A alimente directement plusieurs lignes de cette matrice (intégrité du démarrage, mises à jour sécurisées).
Identification des exigences déjà couvertes par la chaîne existante (Mender, signature des artefacts, HAB) et de celles qui ne le sont pas.
Phase 7 — Plan de mise en conformité (≈ 2 semaines)
Feuille de route priorisée par risque de non-conformité et par coût, avec jalons sur l'échéance du 11 décembre 2027.
Définition de la période de support et de sa politique de mise à jour.
Identification de ce qui relève du produit, de ce qui relève de l'organisation, et de ce qui relève de la documentation.
Phase 8 — Début du développement (le temps restant)
Sélection avec l'équipe de deux à trois chantiers dans la liste suivante, en fonction des résultats de la phase 6 :
Génération automatisée de SBOM (SPDX ou CycloneDX) depuis la chaîne Yocto, versionnée et publiée avec chaque release.
Pipeline de veille CVE sur le contenu de l'image (cve-check Yocto, sources NVD/OSV), avec sortie exploitable par l'équipe et non un simple dump.
Durcissement système : réduction de la surface d'attaque (services, ports, comptes), absence de secret par défaut, chiffrement des données sensibles au repos, politique de mots de passe, journalisation des accès.
Outillage et procédure de divulgation coordonnée de vulnérabilités (contact sécurité, security.txt, gabarits d'avis de sécurité).
Documentation technique et informations utilisateur au sens de l'Annexe II.
Ce volet ne sera pas terminé. L'attendu est un travail exploitable et repris tel quel par l'équipe, pas un prototype jetable.
4. Environnement technique
Matériel : Boundary Devices Nitrogen8M (i.MX8MQ, 4 Go LPDDR4).
Logiciel : Linux, Yocto/dunfell, U-Boot, ARM Trusted Firmware, Mender, Docker.
Outils NXP : uuu (Universal Update Utility), CST (Code Signing Tool), documentation HAB et Security Reference Manual i.MX8MQ.
Outils conformité : SPDX / CycloneDX, cve-check, bases NVD et OSV, plateforme de signalement ENISA.
Réutilisation : PKI HAB et scripts de signature du produit Android existant.
Langages : C (U-Boot, configuration), shell, BitBake/Python (recettes Yocto).
5. Livrables attendus
Patchs ajoutant à la chaîne de build la production d'images imx-boot signées HAB.
Procédure de provisioning usine (eFuses, signature, flash) reproductible.
Procédure de récupération maîtrisée après fermeture du SoC.
Documentation technique du port HAB (différences Android vs Yocto/U-Boot) et mise à jour du README.md projet.
Note de qualification du produit au regard du CRA, argumentée.
Matrice d'analyse d'écart CRA et plan de mise en conformité priorisé et chiffré.
Code et documentation des briques de conformité développées pendant le stage.
6. Références
NXP Application Note AN4581 — Secure Boot on i.MX 50/53/6/7/8 series using HAB.
NXP Code Signing Tool (CST) — documentation et guide d'utilisation.
Règlement (UE) 2024/2847 (Cyber Resilience Act), en particulier les Annexes I, II et V.
ENISA — plateforme et modalités de signalement des vulnérabilités activement exploitées.
ETSI EN 303 645 — exigences de cybersécurité pour les objets connectés grand public.
Rejoignez Steepulse pour contribuer à la sécurisation matérielle de nos produits embarqués et à leur mise en conformité avec les futures exigences européennes de cybersécurité.
Profil recherché
- Formation Bac+5 en cybersécurité : sécurité des systèmes embarqués, sécurité matérielle, ou sécurité logicielle et conformité. Appréciés : architecture ARM et chaîne de démarrage (ROM, bootloader, SPL), Yocto, U-Boot, sécurité des mises à jour OTA. Compétences développées : Secure Boot matériel (HAB), chaîne de démarrage i.MX8, sécurité par accès physique, Yocto/U-Boot, provisioning sécurisé et industrialisation, conformité réglementaire CRA, gestion des vulnérabilités et SBOM.
Compétences techniques essentielles
- Pratique de Linux obligatoire. Programmation et scripting (shell, Python).
- Cryptographie appliquée : signature, PKI, chaîne de confiance. Compréhension du modèle de menace associé.
- Appréciés : architecture ARM et chaîne de démarrage (ROM, bootloader, SPL), Yocto, U-Boot, sécurité des mises à jour OTA.
- Rigueur et sens du risque : le sujet manipule des opérations irréversibles sur le matériel.
Savoir être
Rigueur et précision dans l'exécution des tâches critiques
Capacité d'analyse pour résoudre des problèmes techniques complexes
Esprit d'équipe et excellentes compétences de communication
Curiosité technique et volonté d'apprendre les nouvelles technologies
Autonomie dans la gestion de projets multi-disciplinaires
À propos de nous
XDIGIT est une start-up française spécialisée dans la conception de circuits intégrés et de systèmes électroniques embarqués sur mesure. Nous opérons sur divers marchés (IoT, médical, spatial, automobile, smart city, etc.) et proposons une expertise unique en conception analogique, numérique et mixte.
Nous développons également le circuit MASSAR, un convertisseur analogique-numérique breveté pour des capteurs d’image haute performance, commercialisé sous forme d’IP.
Pourquoi nous rejoindre ?
- Intégrez un environnement dynamique et innovant.
- Contribuez à l’expansion de trois entreprises en pleine croissance.
- Exercez un rôle clé avec une grande autonomie.
- Travaillez avec une équipe passionnée, orientée résultats.
En tant que petite entreprise, nous offrons à chacun de nos collaborateurs l’opportunité d’avoir un impact direct et de contribuer activement au développement de nos projets.
Notre petite structure de type startup encourage un fort esprit entrepreneurial, où chaque talent est valorisé et les idées sont encouragées. Ici, vous pourrez évoluer dans un environnement agile et prendre part à des projets stimulants.
Contact us
- [email protected]
- +33 7 59 55 87 91
