Zhrnutie

  • Mieru zmetkovitosti pri nahrávaní v teréne nevidíte, kým ju nezačnete merať.
  • Konfiguračný drift medzi kusmi je pri odovzdaní neviditeľný a pri integrácii drahý.
  • Vynútenie podpísaného firmvéru sa po spustení výroby ťažko dopĺňa.
  • Zaznamenávanie hashu firmvéru pre každý kus je požiadavka pripravenosti na CRA.

Zmetkovitosť pri flashovaní v teréne

Tímy, ktoré firmware nahrávajú až po expedícii z PCBA, zmetkovitosť obvykle podhodnocujú. Kus, ktorý firmware na pracovisku integrátora neprevezme, ide do opráv, vráti sa alebo skončí v koši, a náklad spadne na iný účet než cena PCBA.

Keď sa zmetkovitosť meria od začiatku do konca, post-produkčné flashovanie bežne produkuje 1 až 4 percentá chýb. Pri dávke 1000 kusov je to 10 až 40 kusov zbytočných opráv alebo strát. Flashovanie na výrobnej strane zrazí túto mieru na väčšine liniek pod 0,5 percenta, pretože zlyhanie sa zachytí na testovacom pracovisku, nie u integrátora.

Konfiguračný rozjazd

Kusy flashované v rôznych časoch, rôznymi revíziami firmwaru a rôznymi operátormi sa rozchádzajú v konfigurácii. Kalibračné hodnoty, sieťové nastavenia, debug flagy. Pri odovzdaní je rozchádzanie neviditeľné a pri integrácii drahé, pretože jeden kus sa správa inak než ďalší.

Flashovanie na výrobnej strane prevedie každý kus rovnakou flashovacou sekvenciou, s rovnakým hashom firmwaru, rovnakou provisioning šablónou a rovnakým podpísaným bootloaderom. Konfiguračný rozjazd padá na nulu.

Vynútenie podpísaného firmwaru

Dopĺňať vynútenie podpísaného bootloaderu až potom, čo je produkt vo výrobe, je bolestivé. Vypálenie poistiek, odovzdanie kľúčov, overovací cyklus, to všetko sa musí dodatočne napchať do procesu, ktorý s tým nepočítal.

Navrhnúť výrobnú linku od začiatku okolo podpísaného firmwaru je naopak triviálne. Najprv sa zapíše bootloader s referenciou na podpisový kľúč, potom aplikácia s overením hashu, nakoniec sa vypáli eFuse a celý reťazec sa uzamkne.

Pripravenosť na CRA

Cyber Resilience Act očakáva dohľadateľnosť firmwaru po kusoch. Kus dodaný dnes môže o tri roky potrebovať bezpečnostnú aktualizáciu a výrobca musí vedieť, s akou verziou firmwaru bol expedovaný.

Flashovanie na výrobnej strane si do databázy loguje hash firmwaru proti sériovému číslu. Flashovanie v teréne taký záznam neprodukuje, iba ak by si ho integrátor viedol osobitne, čo zvyčajne nerobí.

Kedy sa flashovanie na výrobnej strane vyplatí

Zhruba: pri každom produkte, kde sú revízie firmwaru dosť stabilné na to, aby sa dala dávka zafixovať, a kde je cena flashovania v teréne alebo konfiguračného rozjazdu na kus merateľná. Pri väčšine pripojených priemyselných produktov, automatizácie budov, energetiky a riadenia prístupov sa tento prah prekračuje skoro v NPI.

Pri produktoch, kde sa firmware počas NPI mení týždeň čo týždeň, s presunom flashovania do výroby ešte počkajte, kým sa bootloader a podpisové kľúče neustália. Potom to dajte inline.

Zdroje

  • Odborové správy IPC o výrobnom testovaní a flashovaní
  • Espressif, "Secure Boot v2" produkčná dokumentácia
  • NXP, produkčné návody "Secure boot and trust provisioning"

Cenová ponuka pre naprogramované a sériovo očíslované jednotky

Ak tento výskum zodpovedá situácii vášho produktu, pošlite súbory a my naceníme výrobu.