Caricamento sicuro del codice in Trusted Execution Environment (ARM)

In breve, il TEE ha il proprio bootloader.

L'idea di base è che la CPU si avvia dalla ROM. Questa ROM è programmata per caricare un'immagine software dalla memoria permanente, verificare che sia firmata da una chiave pubblica che è memorizzata nella ROM e trasferire l'esecuzione a questa immagine software. Su una piattaforma ARM con TrustZone, la CPU si avvia in modalità protetta, quindi questo primo software, il TEE, viene eseguito in modalità protetta. Ad un certo punto il TEE passa alla modalità non sicura e carica un'altra immagine software: il "sistema operativo ricco", ovvero il sistema operativo principale in esecuzione sulla piattaforma.

MMU con TrustZone separa un mondo sicuro che esegue il TEE e un mondo non sicuro che esegue il sistema operativo ricco. Il mondo non sicuro è meno privilegiato rispetto al mondo sicuro, quindi non può accedere alla memoria del mondo sicuro, nello stesso modo in cui un programma userland non può accedere alla memoria del kernel (sebbene i dettagli tecnici siano in qualche modo diversi). Non c'è molta documentazione disponibile al pubblico su TrustZone e le tecnologie associate, ma è possibile trovare alcuni sul sito web di ARM .

Dal momento che la vita reale non è mai così semplice, ciò che accade nella pratica è una catena in cui la ROM carica un primo bootloader che carica un secondo bootloader, ecc. Finché ogni fase verifica la firma dell'immagine del codice della fase successiva, solo il codice autenticato può essere eseguito. Uno di questi carica un bootloader non sicuro e non autenticato nel mondo normale che a sua volta carica il sistema operativo principale (ad esempio U-Boot e Linux). Questa è una catena di avvio sicura, simile a ciò che Microsoft richiede per Windows 8 . Una catena di avvio sicura garantisce l'esecuzione del solo codice approvato dal produttore dell'hardware. L'idea della separazione TEE è di applicare l'avvio sicuro al TEE, ma non necessariamente al sistema operativo principale.

Si noti che ciò che garantisce l'avvio sicuro è che viene eseguito solo il codice autenticato . Il codice dannoso può essere eseguito se è stato firmato dal produttore dell'hardware per qualsiasi motivo.

Un documento Microsoft §6.7 offre una panoramica di un esempio catena di avvio sicura. Un whitepaper di Texas Instruments descrive una catena di avvio sicura in modo più dettagliato.

Posso rispondere da come le piattaforme basate su TEE di Qualcomm e Trustronic fanno questo.

Who is loading the code? The loader in the OS or does the TEE have its own loader that allows it to load into the OS' environment?

Caricatore in OS o TEE (se ha un caricatore) può caricare il codice / dati e informare TE che il caricamento è fatto. Di solito il suo caricatore laterale OS. Quindi la regione di memoria di codice / dati è contrassegnata come memoria sicura, da TEE, quindi non più accessibile da Rich OS. Quindi può essere autenticato e basato su reult messo in uso.

If the OS loader is loading it how can it be trusted on a rooted device?

Il rooting significa semplicemente che l'utente ha i privilegi di root, quindi è possibile creare / modificare file nel sistema o dati o qualsiasi partizione che di solito è mantenuta non modificabile da un normale utente in Android. Ciò riguarda solo i privilegi dell'utente in Rich OS e quindi solo in modalità non protetta. TEE e altre risorse e risorse sicure risiedono in Secure Memory. Non accessibile nemmeno su telefoni Android con root.

Un po 'di più sul rooting: quando si esegue il comando "fastboot oem unlock", in poche parole, si consente solo il caricamento dei kernel non firmati dal bootloader, e quindi anche le ROM personalizzate. Questo è molto tardi nella catena di avvio probabilmente 4 ° stadio. Le configurazioni di Trustzone avvengono molto presto al 1 ° o 2 ° stadio. Le piattaforme sono ancora al sicuro. Il rooting non offre agli hacker il pieno controllo, se le risorse sicure sono configurate / utilizzate nel modo giusto. Non c'è bisogno di preoccuparsi.