ELHO_CID: uff, tahle diskuze se beojím odehrává ve špatném klubu, ale moderátor snad promine. Já mluvím o opravdovém kontaktním útoku, kdy má útočník fyzický přístup k té věci (čipu). Pro IoT zařízení a útoky z vnějšku "krabice" nebo dokonce útok na dálku přes internet/Bluetooth/atd. jsou ochrany typu secure boot, attestation atd. rozhodně dobrá věc a pokud je to napsané správně, můžou i při děravém stacku nebo chybě v aplikaci zabránit, aby útočník dostal data ven nebo aby dokázal nahrát vlastní firmware.
Nicméně jakmile do obrazu přidáme útoky, kdy si to zařízení může útočník na pár dní půjčit domů a rozebrat, začíná být většina dnešních TrustZone implementací bezbranná, protože ty čipy nejsou stavěné na věci jako side channel/power analysis, glitching, probing atd. Takže s vybavením v řádech stovek až ticíců dolarů se útočník dostane "dovnitř" a ani TrustZone ani FW/loader/kernel napsaný v Rustu ti nepomůže. Viz například tato historka (nRF52840 má TrustZone a je mu to na nic):
nRF52 Debug Resurrection (APPROTECT Bypass) Part 1 - LimitedResultshttps://limitedresults.com/2020/06/nrf52-debug-resurrection-approtect-bypass/Ano, určitě jde vývoj dopředu a v kombinaci TrustZone + unmutable OTP paměť + PUF a podobné věci budou tyto útoky stále těžší, ale bez opravdu bezpečného návrhu daného čipu aby ustál ty běžné útoky (hádání klíčů za běhu z EM záření nebo spotřeby, glitching a aktivní útok na startovací sekvenci za běhu, přímé čtení paměti když se otevře pouzdro...) můžeš jen těžko vymyslet byznys model, ve kterém bys mohl garantovat ochranu věcí, které mají hodnotu větší, než řekněme 1000 dolarů (protože to bude cena, za kterou ti X lidí ochotně takový "běžný" čip vyláme v laboratoři, t.j. dostaneš veškerý kód a data a můžeš vesele začít dumat, jakou další chybu tam mají a jak jí využít už relativně levně na zbytku těchto zařízení rozesetých po světě...)