Zmetkovitost při flashování v poli
Týmy, které firmware nahrávají až po expedici z PCBA, zmetkovitost obvykle podhodnocují. Kus, který firmware na pracovišti integrátora nepřevezme, jde do oprav, vrátí se nebo skončí v koši, a náklad spadne na jiný účet než cena PCBA.
Když se zmetkovitost měří od začátku do konce, post-produkční flashování běžně produkuje 1 až 4 procenta vad. U dávky 1000 kusů je to 10 až 40 kusů zbytečných oprav nebo ztrát. Flashování na výrobní straně srazí tuto míru na většině linek pod 0,5 procenta, protože selhání se zachytí na testovacím pracovišti, ne u integrátora.
Konfigurační rozjezd
Kusy flashované v různých časech, různými revizemi firmwaru a různými operátory se rozcházejí v konfiguraci. Kalibrační hodnoty, síťová nastavení, debug flagy. Při předání je rozcházení neviditelné a při integraci drahé, protože jeden kus se chová jinak než další.
Flashování na výrobní straně provede každý kus stejnou flashovací sekvencí, se stejným hashem firmwaru, stejnou provisioning šablonou a stejným podepsaným bootloaderem. Konfigurační rozjezd padá na nulu.
Vynucení podepsaného firmwaru
Doplňovat vynucení podepsaného bootloaderu až poté, co je produkt ve výrobě, je bolestivé. Vypálení pojistek, předání klíčů, ověřovací cyklus, to všechno se musí dodatečně narvat do procesu, který s tím nepočítal.
Navrhnout výrobní linku od začátku kolem podepsaného firmwaru je naopak triviální. Nejdřív se zapíše bootloader s referencí na podpisový klíč, pak aplikace s ověřením hashe, nakonec se vypálí eFuse a celý řetězec se uzamkne.
Připravenost na CRA
Cyber Resilience Act očekává dohledatelnost firmwaru po kusech. Kus dodaný dnes může za tři roky potřebovat bezpečnostní aktualizaci a výrobce musí vědět, s jakou verzí firmwaru byl expedován.
Flashování na výrobní straně si do databáze loguje hash firmwaru proti sériovému číslu. Flashování v poli takový záznam neprodukuje, ledaže by si ho integrátor vedl zvlášť, což obvykle nedělá.
Kdy se flashování na výrobní straně vyplatí
Zhruba: u každého produktu, kde jsou revize firmwaru dost stabilní na to, aby šlo dávku zafixovat, a kde je cena flashování v poli nebo konfiguračního rozjezdu na kus měřitelná. U většiny připojených průmyslových produktů, automatizace budov, energetiky a řízení přístupů se tento práh překračuje brzy v NPI.
U produktů, kde se firmware během NPI mění týden co týden, s přesunem flashování do výroby ještě počkejte, dokud se bootloader a podpisové klíče neustálí. Potom to dejte inline.
Zdroje
- Oborové zprávy IPC o výrobním testování a flashování
- Espressif, "Secure Boot v2" produkční dokumentace
- NXP, produkční návody "Secure boot and trust provisioning"