Niektoré texty a pasáže použité z mojej diplomovej práce: 
Bezpečná aktualizácia firmvéru v senzorovej sieti na báze ESP32 (Košice, 2021)

Secure Boot je metóda zabezpečenia bootovacieho procesu pre mikrokontroléry ESP32 pred nedôveryhodným firmvérom a bootloaderom, ktorý môže byť do flash pamäte zavedený fyzicky cez UART rozhranie, alebo v aktualizácii. Secure Boot kombinuje metódu overenia digitálneho podpisu firmvéru v procese bootovania a taktiež aj v procese vzdialenej aktualizácie OTA (Over-The-Air) firmvéru.

Toto overenie realizuje softvérový bootloader verejným kľúčom, ktorý je do neho vložený v procese kompilácie. Firmvér je podpísaný súkromným kľúčom. Tento kľúč je vygenerovaný pre eliptickú krivku NIST256p a má dĺžku 256 bitov. Pre samotné podpísanie firmvéru sa používa podpisová schéma ECDSA. Zároveň je Secure Boot rozšírený o overenie softvérového bootloadera (Second-Stage bootloader) pred bootovaním firmvéru. Túto funkcionalitu obsluhuje hardvérový bootloader (First-Stage bootloader) uložený v ROM pamäti.

V princípe ide o výpočet odtlačku (digestu) softvérového bootloadera zapísaného vo flash pamäti na ofsete 0x1000 a jeho porovnanie s referenčným z ofsetu 0x0. Pre výpočet odtlačku sa využíva AES kľúč (použitý iba pre operáciu šifrovania) s dĺžkou 256 bitov. AES kľúč je uložený v jednorazovo programovateľnej pamäti eFuse BLK2 mikrokontroléru ESP32 s veľkosťou 256 bitov, odkiaľ ho nie je možné softvérovo prečítať / prepísať.

Cieľom výpočtu odtlačku a následného overenia je verifikácia, že je softvérový bootloader vo flash pamäti dôveryhodný a zhoduje sa s odtlačkom, ktorý je ako referenčný uložený vo flash pamäti na preddefinovanom ofsete 0x0. Zaručuje tak, že softvérový bootloader je od dôveryhodného vydavateľa, ktorý dokázal pre tento bootloader vytvoriť aj odtlačok s využitím referenčného AES šifrovacieho kľúča (rovnaký je zapísaný v eFuse BLK2), ktorý má k dispozícii lokálne na svojom stroji, kde vyvíja firmvér.

Ak by Secure Boot nebol implementovaný, mohlo by mať za následok spúšťanie neovereného firmvéru, ktorý by mohol podvrhnúť útočník, spoločne s upraveným bootloaderom, ktorý by ignoroval digitálny podpis firmvéru. Secure Boot je možné zapnúť cez Menuconfig v konzolovej aplikácii ESP-IDF v podmenu „Security Features“. Neúspešné overenie bootloadera môže byť spôsobené taktiež aj chýbajúcim odtlačkom na očakávanom ofsete 0x0 vo flash pamäti.

Celý proces tejto metódy využíva princíp reťaze dôvernosti (Chain of Trust). Pokiaľ nie je overený softvérový bootloader, nevykoná sa bootovanie firmvéru, ani overenie jeho digitálneho podpisu. Mikrokontróler ESP32 sa reštartuje v nekonečnej slučke a vypisuje cyklický výpis o neúspešnom overení bootloadera pri každom spustení ESP32. Z dôvodu, že nebol bootloader overený, nevykoná sa pokus o bootovanie firmvéru z dostupných partícií. Nie je splnený predpoklad pre možnosť prístupu k ďalšej fáze bootovacieho procesu pre bootovanie firmvéru z aplikačných partícií (viz. obrázok nižšie).

Z pohľadu prevádzky Secure Bootu je možné zvoliť si jednu z jeho dvoch podporovaných implementácii v prostredí ESP-IDF – „Re-flashable“, ktorá je vhodná pre vývoj aplikácií a umožňuje nahrávať AES šifrovací kľúč viackrát do určitej časti flash pamäte, ktorú hardvérová metóda zabezpečenia používa. Tento režim nie je vhodný pre produkčné (finálne) aplikácie, keďže útočník dokáže získať AES kľúč po prečítaní flash pamäte z dôvodu, že kľúč používaný pre šifrovanie nie je chránený v eFuse, kde môže ku kľúču pristupovať iba hardvérový bootloader. Druhou implementáciou metódy, ktorú je možné použiť je „One-Time Flash“. Tento typ je vhodný pre produkčné aplikácie s jednorazovým zápisom AES šifrovacieho kľúča do eFuse BLK2.

Zároveň je použitie tejto funkcionality permanentné bez možnosti jej vypnutia v budúcnosti. V následujúcej podkapitole je vysvetlená implementácia v prostredí ESP-IDF práve pre „One-Time Flash“ implementáciu Secure Boot. Na obrázku nižšie je základné nastavenie podmenu „Security Features“ v Menuconfigu pre produkčnú verziu Secure Boot s využitím „One-Time Flash“. Ako je z konfiguračného menu zrejmé, firmvér nie je v procese kompilácie podpísaný, keďže je možné zvoliť možnosť automatizovaného vloženia verejného kľúča do softvérového bootloadera (používaný pre overenie digitálneho podpisu firmvéru) v procese kompilácie, alebo podpísanie firmvéru, nie obe možnosti súčasne.

Z toho dôvodu sa podpísanie firmvéru realizuje manuálne v konzolovej aplikácii prostredia ESP-IDF s využitím Python nástroja espsecure.py. Zapnutím tejto funkcionality cez Menuconfig v časti „Security Features“ však ešte nie je Secure Boot plne aktívny, pretože sa musí zapnúť manuálne zápisom AES šifrovacieho kľúča do eFuse BLK2 a zápisom bitu do potvrdzovacej 1-bitovej eFuse ABS_DONE_0, ktorá túto metódu permanentne zapne. Využil som Secure Boot vo verzii V1, ktorého funkčnosť je opísaná v tejto kapitole.

Táto hardvérová funkcionalita existuje aj vo verzii V2, ktorá je však viazaná na modernejšie ESP32 platformy modelov z produkcie posledných rokov (napr. ESP32-S2, ESP32-C6), ktoré využívajú eFuse ABS_DONE_1 pre spustenie Secure Boot V2. Použitý mikrokontróler ESP32-WROOM-32 túto metódu druhej verzie nepodporuje, aj keď má eFuse ABS_DONE_1 k dispozícii.

 

Generovanie šifrovacieho kľúča v ESP-IDF

Šifrovací kľúč AES pre Secure Boot je potrebné najprv vygenerovať. Pre generovanie kľúča je možné využiť kryptografický nástroj espsecure.py. Príkazom espsecure.py generate_ generate flash_encryption_key secure-bootloader-key-256.bin som vygeneroval 256-bitový kľúč s využitím náhodnosti operačného systému. Využíva sa funkcia os.random() v Pythone, ktoré zvyšuje entropiu – náhodnosť kľúča, keďže využíva viac faktorov operačného systému, na ktorom je konzolová aplikácia frameworku ESP-IDF spustená. 

Takto vygenerovaný kľúč je potrebné zapísať do jednorazovo programovateľnej pamäte eFuse BLK2 s veľkosťou 256 bitov, ktorá je pre tento kľúč určená. Pre prácu s eFuses existuje v ESP-IDF nástroj espefuse.py, ktorý sa označuje ako aj eFuse manager. Umožňuje prácu so všetkými eFuses, ktoré sú v ESP32 dostupné. Spomenutá jednorazovo programovateľná eFuse BLK2 je špeciálna systémová eFuse s veľkosťou 256 bitov do ktorej sa zapisuje AES šifrovací kľúč pre funkcionalitu Secure Boot.

Nástrojom espefuse.py som AES šifrovací kľúč zapísal do eFuse BLK2 s využitím príkazu espefuse.py burn_key secure_boot secure-bootloader-key-256.bin. Každý príkaz zápisu do eFuse je potrebné potvrdiť zápisom hodnoty (textu) „BURN“ do konzolovej aplikácie prostredia ESP-IDF pre vykonanie zápisu. Od tohto momentu je eFuse BLK2 chránená pred softvérovým zápisom a čítaním. Pre permanentné zapnutie Secure Boot, je potrebné zapísať aj potvrdzovací bit do eFuse ABS_DONE_0.

Zápis som realizoval príkazom espefuse.py burn_efuse ABS_DONE_0. Potencionálny útočník nedokáže získať kľúč uložený v tejto eFuse, keďže k nej nemá prístup žiadnym softvérovým nástrojom. K predmetnej eFuse BLK2 môže pristupovať už iba hardvér, respektíve hardvérová funkcionalita Secure Boot prostredníctvom hardvérového bootloadera.

Funkcionalita už následne pri pokuse o bootovanie zabezpečuje verifikáciu softvérového bootloadera mikrokontroléra ESP32 zapísaného vo flash pamäti na preddefinovanom ofsete 0x1000. Aby bolo možné verifikovať softvérový bootloader a zabezpečiť tak proces bootovania firmvéru, je potrebné vygenerovať odtlačok (digest), ktorý je výstupom algoritmu SBDA (Secure Bootloader Digest Algorithm) a zapísať ho do flash pamäte na ofset 0x0, kde ho očakáva Secure Boot a používa ho ako referenčný pre overenie.

 

SBDA algoritmus

Algoritmus SBDA je spúšťaný hardvérovým bootloaderom. Vykoná načítanie AES šifrovacieho kľúča z eFuse BLK2 v reverznej bitovej reprezentácii a obraz softvérového bootloadera z flash pamäte z ofsetu 0x1000. Pred obraz bootloadera dosadí 128-bajtový vygenerovaný inicializačný vektor. Algoritmus vykoná zarovnanie obrazu bootloadera modulo 128 a doplní 0xFF (hexadecimálna hodnota) do reprezentácie obrazu pre dosiahnutie dĺžky 128 bajtov.

Na každých 16 bajtov otvoreného textu obrazu bootloadera sa aplikuje bloková šifra AES256 v ECB móde s využitím AES šifrovacieho kľúča z eFuse BLK2 s dĺžkou 256 bitov. Výsledný šifrovaný text má reverznú bitovú reprezentáciu. Algoritmus vymení bajt každého 4- bajtového slova šifrovaného textu, vypočíta hašovanú hodnotu SHA-512 výsledného šifrovaného textu. Výstupom je 192-bajtový reťazec, ktorý je tvorený 128-bajtovým inicializačným vektorom a 64-bajtovou hašovanou hodnotou SHA-512 zo šifrovaného textu.

Odtlačok je možné algoritmom SBDA vygenerovať aj lokálne použitím nástroja espsecure.py. Princíp algoritmu SBDA je totožný, využijeme lokálne dostupný vygenerovaný AES šifrovací kľúč „securebootloader-key-256.bin“, ktorý sme do eFuse v predchádzajúcom kroku zapísali. Príkazom espsecure.py digest_secure_bootloader --keyfile secure-bootloader-key-256.bin --output ./bootloader-digest.bin build/bootloader/bootloader.bin sa vygeneruje odtlačok „bootloader-digest.bin“, ktorý je možné zapísať do flash pamäte na preddefinovaný ofset 0x0.

Príkaz má vstup – šifrovací AES kľúč „secure-bootloader-key-256.bin“ s dĺžkou 256 bitov v binárnom formáte (rovnaký bol zapísaný do eFuse BLK2) a obrazu bootloadera „bootloader.bin“ z priečinku build v projekte Native OTA (s podporou vzdialenej aktualizácie firmvéru). Pre generovanie odtlačku musí mať vývojár k dispozícii šifrovací kľúč a zodpovedá za jeho archiváciu a ochranu. Pri zápise odtlačku do flash pamäte je potrebné zvoliť cieľový ofset na 0x0, kde ho očakáva hardvérový bootloader ako referenciu pre porovnanie vypočítaného odtlačku softvérového bootloadera.

Zápis odtlačku do flash pamäte som realizoval použitím príkazu: esptool.py write_flash 0x0 bootloaderdigest.bin. Po zapísaní odtlačku do flash pamäte a úspešnom overení odtlačku bootloadera je možné pristúpiť k ďalšej fáze bootovacieho procesu – k bootovaniu firmvéru. Pri spustení mikrokontroléru sa vykoná hardvérové vypočítanie odtlačku, kedy hardvér (ROM bootloader) pristúpi k prečítaniu obsahu eFuse BLK2 a zo známeho ofsetu, kde je zapísaný softvérový bootloader (0x1000) sa prevezme jeho obraz.

Vykoná sa algoritmus SBDA a výsledný odtlačok porovná hardvérový bootloader s odtlačkom uloženým vo flash pamäti na ofsete 0x0, ktorý slúži ako referenčný. V prípade, že sú oba odtlačky identické, hardvérový bootloader umožníspustiť softvérový bootloader a ten pristúpi k bootovaniu firmvéru (s overením jeho digitálneho podpisu pri bootovaní, ale aj pri vzdialenej aktualizácii firmvéru…). Ak sú odtlačky rozdielne, bootovanie je zakázané hardvérovou funkcionalitou Secure Boot.

Tento spôsob ochrany je efektívny v prípade, ak by útočník získal fyzický prístup ku mikrokontroléru a pokúsil by sa spustiť na mikrokontroléri svoj program. V procese nahrávania firmvéru cez USB-UART rozhranie sa prepíše aj softvérový bootloader, tabuľka partícií na základe konfigurácie prostredia z ktorého sa nahrávanie firmvéru realizuje. Vypočítaný odtlačok sa tak nebude zhodovať s odtlačkom zapísaným na ofsete 0x0 (za predpokladu, že nebude prepísaný) pri nahrávaní firmvéru.

V prípade, ak by útočník dokázal zapísať iba firmvér na konkrétny ofset a prepísal by aj príznak v OTA_DATA partícií, firmvér by nabootovaný nebol, keďže nie je digitálne podpísaný kľúčom, ktorý útočník k dispozícii nemá. Efektívne je Secure Boot doplniť o funkcionalitu Flash Encryption v produkčnej, ktorá umožňuje šifrovať všetky aplikačné partície, referenčný odtlačok a obraz softvérového bootloadera, aby tento obsah flash pamäte nebol potencionálnym útočníkom získaný s možnosťou analýzy pre prelomenie AES šifrovacieho kľúča.

Prístupov 9624

Kvalita článku