EMB_89

EMBEDDED 89 • SETTEMBRE • 2023 60 SOFTWARE | CYBERSECURITY retto, oppure potrebbe utilizzare un canale https sicuro per fornire un flusso infinito di dati in risposta a una ri- chiesta di aggiornamento da parte del client. Questo è un elenco tutt’altro che completo dei punti debo- li del metodo https. Inoltre, poiché una trasmissione https è firmata tramite un’unica chiave, la compromissione del- la chiave comporta a sua volta la compromissione dell’ag- giornamento protetto da questo metodo. Un framework multiruolo e multichiave: la risposta alle vulnerabilità degli aggiornamenti Grazie alla sua risposta globale a un’ampia serie di meto- di di attacco, TUF è stata riconosciuta come la tecnologia più efficace per la protezione degli aggiornamenti. TUF migliora la sicurezza “aggiungendo registrazioni verifica- bili sullo stato di un repository o di un’applicazione”. Ag- giungendo metadati contenenti informazioni sulle chiavi di firma affidabili, funzioni di “hash” crittografiche dei file, le firme sui metadati, i numeri di versione dei meta- dati e la data dopo la quale i metadati devono essere con- siderati scaduti, si crea un record che può essere control- lato per verificare l’autenticità dei file di aggiornamento. Il core del metodo TUF è quindi costituito da: • Metadati – diverse forme di informazioni firmate che consentono al client di giudicare se il file di aggiorna- mento sia attendibile o meno • Ruoli multipli e separazione delle responsabilità tra di essi TUF definisce quattro ruoli per un sistema di aggior- namento, ognuno dei quali è protetto da una chiave fir- mata. Il root è responsabile della firma della chiave. Il timestamp verifica la “freschezza” della vista di aggior- namento fornita dal repository. Lo snapshot mostra la versione più recente dei file di aggiornamento. E il target fornisce metadati dettagliati su un file di aggiornamento. I metadati target consentono al client di verificare se un file di aggiornamento sia rilevante e di visualizzare altre informazioni, come la dimensione del file. Quindi, a differenza di https, in cui il modello di trust in una singola chiave implica la fiducia nell’intero sistema di aggiornamento, in TUF questo trust è vincolato al tempo e al ruolo. Il suo modello di trust compartimentalizzato significa che ci si può fidare solo dei file che il ruolo di root stabilisce possano essere inviati. La separazione delle responsabilità significa che, anche se la chiave associata a un ruolo è compromessa, gli altri ruoli possono continuare a operare in modo sicuro. Inol- tre, consente ad altri ruoli di revocare e sostituire pronta- mente la chiave di un ruolo compromesso. Come semplificare l’implementazione di TUF in un flus- so di sviluppo embedded TUF non è di per sé un software di aggiornamento: è un livello di sicurezza che viene aggiunto al sistema di aggior- namento di qualsiasi dispositivo embedded di un OEM. La domanda per lo sviluppatore descritto in precedenza – a corto di risorse e con scadenze sempre stringenti per il go-to-market – è se questo livello aggiuntivo possa essere applicato senza richiedere un onere sostanziale, anche in termini di tempo, per lo sviluppatore stesso. Le risposte alla domanda sono due. La prima è una rispo- sta controfattuale: cosa succede se un OEM non adotta TUF? E se l’esposizione a un aggiornamento compro- messo si traducesse in un attacco riuscito a un gruppo di dispositivi usati sul campo? Il costo e il tempo necessario per ripristinare i dispositivi compromessi e per risarcire potenzialmente gli utenti saranno probabilmente di gran lunga superiori al costo di un’adeguata implementazione della sicurezza quando il prodotto è in fase di sviluppo. La seconda risposta è più pratica: Gli OEM possono oggi sfruttare l’integrazione TUF offerta da una nuova gene- razione di piattaforme software universali basate su Li- nux per dispositivi embedded connessi. L’obiettivo di un prodotto come la piattaforma FoundriesFactory è fornire un sistema di distribuzione e installazione (deployment) delle applicazioni sicuro per tutta la vita, in modo che qualsiasi OEM possa evitare i costi e le difficoltà di svilup- po, sicurezza e manutenzione della propria piattaforma basata su Linux. (Fonte: Foundries.io)