IT201900017534A1 - "Sistema di elaborazione comprendente apparato di calcolo di tipo "trust anchor" e corrispondente procedimento" - Google Patents

Description

DESCRIZIONE dell’invenzione industriale intitolata:

"Sistema di elaborazione comprendente apparato di calcolo di tipo "trust anchor" e corrispondente procedimento”

TESTO DELLA DESCRIZIONE

Campo tecnico

La presente descrizione si riferisce ad un sistema di elaborazione configurato per eseguire operazioni trusted comprendente almeno un modulo di calcolo host comprendente un’unità di elaborazione host e mezzi di memoria host ed un hardware trust anchor. Preferibilmente il sistema di elaborazione con l’almeno un modulo host e hardware di tipo trust anchor fa parte di un Sistema su Chip, in particolare detto almeno un modulo host essendo un’ECU operante in un veicolo.

Descrizione della tecnica anteriore

Un Hardware Trust Anchor (HTA) è un dispositivo di calcolo locale ed isolato che avvia la catena di fiducia ed esegue entrambe funzioni critiche del sistema e funzioni di sicurezza, comprendenti il monitoraggio proattivo del processo di avvio e arresto del processo se è rilevata una manomissione.

In uno scenario automobilistico generale i sistemi di elaborazione come l’Unità di Controllo Elettronico o Electronic Control Unit (ECU) si basano su uno o più SoCs (Sistema su Chip o System on Chip), composti da un’unità di elaborazione di applicazioni, cioè Application Core, per funzioni di veicolo, e da un HTA per il supporto della sicurezza. Al fine di rafforzare l’ECU contro attacchi esterni (attivazione non autorizzata di caratteristiche del veicolo, lettura di materiale delle chiavi o di keying sensibile, manipolazione del software ed altri) è di conseguenza utilizzata la tecnologia dell’Hardware Trust Anchor (HTA).

L’HTA può comprendere un’unità di elaborazione che utilizza un sistema operativo in tempo reale (RTOS) che incorpora un insieme di meccanismi utilizzati per consolidare la sicurezza di base lato HTA, che è chiamato quindi sistema operativo in tempo reale con sicurezza rafforzata. Nel calcolo, il rafforzamento è solitamente il processo di rendere sicuro un sistema riducendo la sua superficie di vulnerabilità.

Queste tecniche di protezione sono di conseguenza configurate per rilevare/reagire ad attacchi in modo più efficace e limitare la loro capacità di eseguire strumentalizzazioni.

Un HTA è impiegato per operazioni di sicurezza che comportano informazioni riservate e sensibili quali:

• Gestione delle chiavi;

• Gestione di Certificati;

• Operazioni crittografiche;

• Protezione Software (avvio sicuro e aggiornamento sicuro);

• Protezione dei dati (immagazzinamento sicuro e comunicazione sicura) utilizzando meccanismi di accesso per leggere e scrivere dati sensibili e tecniche di criptaggio per ridurre la visibilità dei dati;

Quindi, conseguentemente, il sistema operativo in tempo reale con sicurezza rafforzata dovrebbe essere in grado di:

• eseguire simultaneamente operazioni sicure multiple;

• commutare tra varie entità (processi o attività (task)) secondo alcune logiche e politiche di schedulazione predefinite;

• garantire e preservare la riservatezza (isolamento delle informazioni)

• assicurare che una funzione generica sia eseguita e che il suo tempo di esecuzione sia noto

Il sistema operativo in tempo reale con sicurezza rafforzata, utilizzato per l’HTA, può essere un ambiente operazionale non modificabile statico. Ciò significa che gli scopi dell’applicazione, task, eventi, risorse non possono essere creati o cancellati durante l’esecuzione dell’applicazione. In un sistema sicuro la correttezza (integrità) dei dati ed altre sezioni di memoria dovrebbero essere il requisito di base.

Oggi, la maggior parte delle ECU automobilistice supportano lo scaricamento del software per essere in grado di aggiornare il software di applicazione o i dati in qualsiasi momento. A seconda dei requisiti di OEM, alcuni controlli sono effettuati durante lo scaricamento del software per garantire che il nuovo software sia valido, durante l’accensione dell’ECU o per garantire che il software sia ancora valido o in una combinazione dei due.

Vi sono vari tipi di procedimenti per gestire le informazioni di validità.

Ad esempio, può essere fornito un controllo di integrità, solitamente richiesto per ragioni di sicurezza, che si basa sulla somma di controllo/CRC (Controllo di Ridondanza Ciclica - Cyclic Redundant Check), calcolato sui dati software non volatili e confrontato con un valore di riferimento. Se la somma di controllo è corretta, è ipotizzata l’integrità di un blocco software completo. Tra l’altro, gli algoritmi della somma di controllo come il CRC non forniscono un controllo di autenticità poiché non vi è parametro segreto coinvolto durante il calcolo della somma di controllo.

Un tale controllo di autenticità è invece richiesto da alcune ECU, che richiedono che solo il software o dati da una sorgente legittima sia utilizzato sull’ECU (ad es. in ECU pertinenti alla sicurezza o come protezione alla sintonizzazione). L’autenticazione è normalmente eseguita tramite il calcolo di una firma crittografica sui dati software non volatili. La firma può essere o fornita dall’OEM o dal fornitore di ECU.

Algoritmi di calcolo della firma combinano un calcolo di hash e routine crittografiche basate su hardware, come quelle eseguite nei moduli 122a-122e, o basate su software, per assicurare l’integrità ed autenticità del software scaricato. Nel caso in cui detto Hardware Trust Anchor (HTA) non comprenda i moduli 122a-122b, o comprenda solo un sottoinsieme di essi, i calcoli sono eseguiti nel software, e nessun hardware speciale è richiesto per eseguire operazioni crittografiche.

I suddetti procedimenti possono anche essere utilizzati per controllare le informazioni di validità al tempo di esecuzione o runtime.

Attualmente, al fine di soddisfare solamente i requisiti di sicurezza, è utilizzato solo il controllo di integrità al runtime. Ma ancora, in questo modo non è possibile rilevare manipolazioni sull’ECU originale durante il normale funzionamento della stessa ECU.

Scopo e sintesi

Uno scopo di una o più forme di attuazione è di superare le limitazioni intrinseche nelle soluzioni conseguibili dalla tecnica anteriore.

Secondo una o più forme di attuazione, quello scopo è conseguito grazie ad un sistema avente le caratteristiche specificate nella rivendicazione 1. Una o più forme di attuazione possono far riferimento ad un corrispondente sistema.

Le rivendicazioni formano una parte integrante dell’insegnamento tecnico qui fornito in relazione alle varie forme di attuazione.

Secondo la soluzione qui descritta, la soluzione si riferisce ad un sistema di elaborazione configurato per eseguire operazioni trusted comprendente almeno un modulo di calcolo host comprendente un’unità di elaborazione host e mezzi di memoria host ed un hardware trust anchor, detto hardware trust anchor, che comprende una rispettiva unità di elaborazione sicura, un modulo di elaborazione hardware dedicato ad un’operazione crittografica e mezzi di immagazzinamento sicuro, essendo configurati per immagazzinare ed eseguire un sistema operativo sicuro in tempo reale, detto sistema operativo sicuro essendo configurato per eseguire un controllo di validità sul software che è utilizzato nel sistema di elaborazione

in cui detto sistema operativo sicuro è configurato per eseguire un controllo di autenticità del runtime, che controlla l’integrità del codice software al runtime, detto controllo di autenticità del runtime comprendendo identificare blocchi firmati software ed una corrispondente Intestazione e blocco di Dati residenti almeno in una memoria di programma del detto hardware trust anchor, e, eventualmente, anche in una memoria di programma dell’host, per l’esecuzione, ed eseguire per ciascun blocco firmato software,

una prima fase di controllo della validità di certificati associati a detti blocchi software firmati, una seconda fase di controllo della validità di un’intestazione di detto blocco software firmato,

una terza fase di controllo della validità di un hash dei dati di detti blocchi software firmati, e

se una di dette fasi di controlli di validità rileva un’anomalia, scrivere in un registro sicuro informazioni riguardanti l’anomalia rilevata,

detto sistema operativo sicuro essendo configurato per eseguire detto controllo di autenticità del runtime in un task che ha la priorità più alta rispetto agli altri servizi host o di hardware trust anchor.

La soluzione qui descritta è anche diretta ad un corrispondente procedimento per eseguire operazioni trusted nel suddetto sistema di elaborazione, comprendente l’immagazzinamento ed esecuzione di un sistema operativo sicuro in tempo reale che esegue un controllo di validità sul software che è utilizzato nel sistema di elaborazione, detto procedimento comprendendo

eseguire un controllo di autenticità del runtime, che controlla l’integrità del codice software al runtime, detto controllo di autenticità del runtime comprendendo identificare un blocco firmato software ed una corrispondente Intestazione ed Intestazione del blocco di Dati residenti in una memoria di programma del detto hardware trust anchor, e eventualmente, anche in una memoria di programma dell’host, per l’esecuzione, ed eseguire e per ciascun blocco firmato software,

una prima fase di controllo della validità di certificati associati a detti blocchi software firmati, una seconda fase di controllo della validità di un’intestazione di detto blocco software firmato,

una terza fase di controllo della validità di un hash dei dati di detti blocchi software firmati, e

se una di dette fasi di controlli di validità rileva un’anomalia, scrivere in un registro sicuro informazioni riguardanti l’anomalia rilevata,

detto sistema operativo sicuro essendo configurato per eseguire detto controllo di autenticità del runtime in un task che ha la priorità più alta rispetto agli altri servizi del modulo host o di hardware trust anchor.

Breve descrizione dei disegni

Le forme di attuazione verranno ora descritte puramente a titolo di esempio non limitativo facendo riferimento ai disegni annessi, in cui:

- Figura 1 rappresenta schematicamente una forma di attuazione del sistema di elaborazione qui descritto;

- Figura 2 illustra schematicamente lo spazio degli indirizzi di una memoria utilizzata dal sistema di elaborazione qui descritto;

- Figura 3 illustra schematicamente l’area di memoria delle memorie utilizzate dal sistema di elaborazione qui descritto;

- Figura 4 rappresenta un diagramma di flusso di una procedura di controllo di autenticità implementata dal sistema di elaborazione qui descritto;

- Figura 5 rappresenta un diagramma di temporizzazione che rappresenta le fasi operative del sistema di elaborazione qui descritto;

- Figura 6 rappresenta un diagramma a blocchi di una pila o stack di una memoria del sistema di elaborazione qui descritto;

- Figura 7 rappresenta un diagramma di flusso di una procedura di controllo di trabocco di uno stack overflow implementata dal sistema di elaborazione qui descritto;

- Figura 8 rappresenta un diagramma di flusso di una procedura di rilevamento implementata dal sistema di elaborazione qui descritto.

Descrizione dettagliata delle forme di attuazione La descrizione che segue illustra vari dettagli specifici volti ad una comprensione approfondita delle forme di attuazione. Le forme di attuazione possono essere implementate senza uno o più dei dettagli specifici, o con altri procedimenti, componenti, materiali, ecc. In altri casi, note strutture, materiali, o operazioni non sono illustrati o descritti nel dettaglio in modo che i vari aspetti delle forme di attuazione non saranno resi poco chiari.

Il riferimento ad "una forma di attuazione" nel quadro generale della presente descrizione intende indicare che una particolare configurazione, struttura, o caratteristica descritti in relazione alla forma di attuazione è compresa in almeno una forma di attuazione. Analogamente, frasi quali "in una forma di attuazione", che possono essere presenti in vari punti della presente descrizione, non fanno necessariamente riferimento alla singola e allas stessa forma di attuazione. Inoltre, particolari conformazioni, strutture, o caratteristiche possono essere combinate in modo appropriato in una o più forme di attuazione.

I riferimenti qui utilizzati sono intesi semplicemente per comodità e pertanto non definiscono la portata di protezione delle forme di attuazione.

In figura 1 è mostrato un sistema di elaborazione 10 che può corrispondere ad esempio ad un’ECU su un SoC per un’applicazione automobilistica, ad es. nei sistemi di controllo di motori o altre funzioni di un veicolo, che comprende un’unità di elaborazione di applicazioni, cioè un nucleo di applicazione 11 ed un hardware trusted anchor (HTA) 12. Il nucleo di applicazione 11 comprende una memoria non volatile 111, una memoria RAM 112, un’interfaccia di bus 114 ad esempio per comunicare con un bus di veicolo ed una CPU di applicazione 113. L’HTA 12 comprende un immagazzinamento sicuro 121, comprendente una memoria non volatile sicura 121b ed una memoria RAM sicura 121a. L’HTA 12 comprende inoltre un’unità di elaborazione sicura 123, un modulo di interfaccia HTA 124 ed un modulo di accelerazione hardware crittografico 122, che può contenere un motore di hash 122a per calcolare valori di hash di dati software, un cripto motore simmetrico 122b per eseguire algoritmi di crittografia simmetrici ed un cripto motore asimmetrico 122c per eseguire algoritmi di crittografia asimmetrici, successivamente un modulo generatore casuale 122d che può comprendere dei TRNG e o dei PRNG ed anche un modulo di contatori 122d.

Il software del sistema operativo in tempo reale con sicurezza rafforzata, essendo esso stesso un software, è normalmente diviso nella memoria, cioè l’immagazzinamento sicuro 121, nelle seguenti sezioni, come mostrato in figura 2, che rappresenta schematicamente lo spazio degli indirizzi della memoria 121 dell’HTA 12 dove risiede il sistema operativo, indicato collettivamente con HOS:

- Testo o Codice Sorgente TXS: area di memoria che immagazzina il codice eseguibile del programma. Questo blocco di memoria è solitamente di sola lettura.

- Dati o flash di dati DT: area di memoria che immagazzina variabili statiche/globali che sono inizializzate dal programmatore. Questa è anche la sezione di memoria dove il SO-Applicazioni possono avere dati privati.

Memoria BSS (Blocco Avviato da Simbolo - Block Started by Symbol) BS: area di memoria che immagazzina variabili statiche/globali non inizializzate. Questo segmento verrà riempito di zeri dal sistema operativo, in modo che tutte le variabili non inizializzate siano inizializzate con zeri.

Memoria Heap HP: L’heap è utilizzato per fornire uno spazio per l’allocazione di memoria dinamica.

Stack SS: Questa è la sezione di memoria volatile (RAM) 121a dove variabili locali, definite all’interno di funzioni, registri e dati relativi a chiamate di funzione, quali di ritorno sono spinte durante l’esecuzione dei task. Ciascun task può avere la propia area di stack.

L’Area di memoria di testo TXS e l’area di memoria di dati DT sono la memoria non volatile 121b, invece l’area di memoria BSS BS, l’area di memoria heap HP e stack SS sono la memoria volatile 121a.

Il sistema operativo in tempo reale di rafforzamento della sicurezza per l’HTA qui descritto è configurato per controllare le memorie non volatili e volatili attraverso procedure specifiche e diverse comprendenti un

- una procedura di Controllo di Autenticità del Runtime 500 per la memoria non volatile, dove la proprietà di autenticità è controllata tramite crittografia;

- una procedura di Rilevamento di Stack Overflow 600 per lo Stack SS (memoria volatile 121a), dove la quantità di stack utilizzato SS è controllata rispetto a limiti statici.

La procedura di Controllo di Autenticità del Runtime 500 è una tecnica di rafforzamento, basata sul procedimento di autenticità, che consiste nel mantenere sotto controllo l’integrità del codice al runtime. Ciò è effettuato in parallelo alle normali operazioni di sistema comprendenti l’avvio, dove l’autenticità è verificata inziando da una radice di fiducia, mentre le altre volte può essere eseguita con una frequenza che può essere collegata ad eventi esterni (quali aggiornamenti di parti del codice) o meccanismi periodici predefiniti o sfruttando momenti di inattività dell’HTA.

In questo modo il sistema operativo in tempo reale rafforzato impedisce ad un sistema compromesso di barare con i propri contenuti di memoria.

Questa tecnica di rafforzamento si avvantaggia del fatto che l’HTA sia ottenuto, come mostrato in figura 1, come un nucleo aggiuntivo con accesso completo alla memoria flash dell’ECU. Come un risultato, la procedura di Controllo di Autenticità del Runtime 500, sviluppata per controllare solo che la detta memoria non volatile dell’hardware trust anchor, potrebbe essere configurata per validare l’integrità del codice dell’intera memoria flash senza causare alcun impatto o ritardo sulle applicazione critiche per la sicurezza eseguite sul nucleo host.

Per questa ragione, e per generalizzare la sua descrizione, è qui ipotizzato che la procedura di Controllo di Autenticità del Runtime 500 sia configurata per controllare l’intera memoria flash.

La procedura di Controllo di Autenticità del Runtime 500 ha utilizzato un meccanismo di verifica basato su Blocchi SW Firmati, e Certificati.

Come mostrato in figura 3, che mostra schematicamente la memoria non volatile 111 dell’host 11 e la memoria non volatile 121b dell’HTA 12, i blocchi SW Firmati SSB, cioè blocchi software a cui è applicata una firma digitale che fornisce l’autenticità ed integrità dei dati, sono immagazzinati in una memoria di programma nella memoria non volatile 111 e 121b, in particolare rispettivamente, una memoria flash, dell’host 11 e hardware trust anchor 12, mentre i Certificati C ed, eventualmente, un registro sicuro SL che fornisce informazioni riguardanti un’anomalia rilevata, come meglio spiegato nel seguito sono immagazzinati nella memoria non volatile 121b, che ad esempio comprende la memoria flash del programma e la memoria flash di dati, nell’immagazzinamento sicuro 121, utilizzato per immagazzinare anche tutti i dati sensibili (ad es. chiavi).

I blocchi SW Firmati SSB corrispondono ai dati binari che sono programmati nella memoria flash dell’hardware di tipo trust anchor 12 ed, eventualmente, anche nell’host 11, specificatamente un’ECU.

Vi sono vari blocchi SW Firmati SSB nell’ECU. L’host e l’HTA hanno entrambi una rispettiva memoria non volatile comprendente una memoria flash del programma ed una memoria flash dei dati, di conseguenza il SSB può essere distribuito nell’host e nell’HSM. Essi sono eseguiti in tempi diversi ed hanno scopi diversi. Ad esempio nella memoria flash dell’host:

Bootloader BL: è un pezzo di codice che esegue prima di qualsiasi codice di applicazione;

Applicazione APP: è un pezzo di codice che esegue dopo il Bootloader;

Calibrazione CLB: è un pezzo di codice che contiene dati necessari affinché l’Applicazione lavori in modo appropriato.

Nella memoria flash dell’hardware trust anchor:

Boot: è un pezzo di codice che è in esecuzione prima che qualsiasi sistema operativo sia in esecuzione;

Applicazione APP: è un pezzo di codice che esegue dopo che il sistema operativo è in esecuzione. Questo pezzo di codice può comprendere il sistema operativo in tempo reale;

Ciascun blocco SW firmato SSB è associato ad alcune informazioni, chiamate metadati che hanno due sezioni, il SSBH di Intestazione e il SSBD di Dati:

- il campo SSBH di Intestazione contiene informazioni riguardanti i contenuti del blocco così come tutti gli hash crittografici e firme;

- il campo SSBD di Dati è il blocco di dati che è stato determinato per necessitare la prova di autenticità ed integrità.

Un Certificato (o certificato digitale) è un incapsulamento di una chiave pubblica utilizata per comunicare lo scopo e dimostrare l’appartenenza e validità. E’ firmato da un’Autorità di Certificati per convogliare la fiducia dei contenuti del certificato.

Il certificato a titolo di esempio non limitativo è conforme al certificato X.509v3 e codificato in formato DER ASN.1.

Ad esempio vi può essere un certificato radice nell’HTA che rappresenta il certificato più alto dal punto di vista dell’ECU e non può essere validato rispetto ad un altro certificato. Vi sono certificati del software di applicazione in esecuzione nell’host e dello stesso software host (ad es. bootloader) che rappresentano certificati intermedi dal punto di vista dell’ECU e sono validati rispetto a tale certificato radice.

Tipicamente, la procedura di Controllo di Autenticità del Runtime 500 è un task a bassa priorità (cioè un task di sfondo) implementato nell’HTA 12 per non interferire con altri servizi di runtime richiesti dall’host. In particolare non dovrebbe superare un ritardo consentito della loro esecuzione.

Tuttavia, è necessario evitare anche il fatto che un attaccante o un host troppo esigente 11, che chiede tante operazioni all’HTA 12, possa impedire al Controllo di Autenticità del Runtime 500 di eseguire e rilevare la manomissione del software. Allo stesso tempo deve essere evitato il fatto che il tempo per verificare l’intero flash superi un valore predefinito.

Per unire queste visioni opposte, il Controllo di Autenticità del Runtime esegue in un task periodico che ha la priorità più alta rispetto ad altri servizi host/HTA e i controlli sono divisi in n fasi di durata configurabile.

In figura 4 è mostrato un diagramma di flusso che rappresenta la procedura di Controllo di Autenticità del Runtime 500.

Il Controllo di Autenticità del Runtime 500, comprende identificare in una fase 505 i blocchi firmati software SSB ed una corrispondente Intestazione SSBH e blocco di Dati (SSBD) residenti in una memoria di programma del detto hardware trust anchor 12, ed eventualmente, anche in una memoria di programma 111 dell’host 11, per l’esecuzione, e che esegue per ciascun blocco firmato software SSBj, j essendo un indice di identificazione del blocco firmato, da zero ad un numero N di blocchi software firmati identificati SSB, in una fase 510 il controllo della validità di ciascun certificato C relativo a ciascun Blocco SW firmato SSB. Il controllo della validità di ciascun certificato comprende il fatto che qualsiasi nuovo certificato da immagazzinare nell’HTA 12 debba essere verificato con un altro certificato immagazzinato nell’HTA 12, a meno che esso sia un certificato auto-firmato.

Successivamente in una fase 520 è verificato che il campo di firma di intestazione SSBH del Blocco SW firmato SSBj corrente, HeaderSignature, che garantisce l’autenticità ed integrità dei contenuti dell’intestazione del blocco. Il campo contiene una firma digitale dall’inizio dell’intestazione attraverso la lunghezza.

Successivamente, in una fase 530 è verificato l’hash del blocco di codice di Blocco SW firmato SSBj corrente: il campo FileDigest nell’intestazione del codice di Blocco SW firmato corrente definisce il digest SHA-256 conforme calcolato sul blocco di Dati;

il controllo è superato solo se il campo FileDigest è uguale al digest SHA-256 conforme calcolato, tramite il Controllo di Autenticità del Runtime, sul blocco di Dati, in particolare nel modulo di accelerazione hardware crittografico 122, in particolare tramite il motore di hash 122a per calcolare valori di hash.

Se nelle fasi di controllo 510, 520 o 530 è rilevata un’anomalia, in una fase 550 è controllato se un registro sicuro SL è già stato creato per il SSB controllato. In negativo in una fase 560 un registro sicuro SL è creato nella memoria di dati (memoria non volatile 121b) dell’HTA 12 che scrive in esso informazioni riguardanti l’anomalia rilevata, cioè è richiamato un accesso sicuro, altrimenti il registro sicuro SL già creato è aggiornato. In generale se una di tali fasi di controllo 510, 520, 530 della validità rileva un’anomalia, è eseguita una scrittura in un’informazione di registro sicuro SL riguardante l’anomalia rilevata.

In figura 5 è mostrato un diagramma temporale, che mostra che, data una durata DH per l’esecuzione di servizi richiesti dall’host 11 all’HTA 12, una porzione della procedura di autenticazione 500 è eseguita per un intervallo di durata DR con un periodo T avente una lunghezza tale da contenere una durata di servizio DH di diversi servizi host.

Di conseguenza, come appena descritto sopra, in una forma di attuazione il sistema di elaborazione 10 configurato per eseguire operazioni trusted comprende almeno un modulo di calcolo host 11 comprendente un’unità di elaborazione host 113 e mezzi di memoria host 111,112, ad es. volatile e non-volatile, ed un hardware trust anchor 12, l’hardware trust anchor 12 comprendendo una rispettiva unità di elaborazione sicura 123, un modulo di elaborazione hardware 122 dedicato ad un’operazione crittografica e mezzi di immagazzinamento sicuro 121, dove l’hardware trust anchor 12 e configurato per immagazzinare ed eseguire un sistema operativo sicuro in tempo reale HOS, che è configurato per eseguire un controllo di validità sul software che è utilizzato nel sistema di elaborazione 10, in cui detto sistema operativo sicuro is configurato per eseguire specificatamente un controllo di autenticità del runtime 500, che controlla l’integrità del codice software al runtime, detto controllo di autenticità del runtime 500 comprendendo

identificare 505 almeno blocchi firmati software SSB ed una corrispondente Intestazione SSBH e blocco di Dati SSBD residenti in una memoria di programma, cioè memoria non volatile 121b, del detto modulo di calcolo hardware trust anchor 12 per l’esecuzione, ed eventualmente anche in una memoria di programma, cioè memoria non volatile 111, dell’host, ed eseguire per ciascun blocco firmato software SSB,

una prima fase 510 di controllo della validità di certificati C associati a detti blocchi software firmati SSB,

una seconda fase 520 di controllo della validità di un’intestazione SBBH di detto blocco software firmato SSB, una terza fase 530 di controllo della validità di un hash dei dati SSBD di detti blocchi software firmati (SSB), e

se una di tali fasi di controllo 510, 520, 530 della validità rileva un’anomalia, scrivere in un registro sicuro SL informazioni riguardanti l’anomalia rilevata, cioè creare un registro sicuro SL, comprendente informazioni riguardanti l’anomalia rilevata, o scrivere l’anomalia nel tale registro sicuro SL,

il sistema operativo sicuro HOS essendo configurato per eseguire detto controllo di autenticità del runtime 500 in un task che ha la priorità più alta PL rispetto agli altri servizi host 11 o di hardware trust anchor 12.

Il sistema di elaborazione 10 implementa anche una procedura di Rilevamento di Stack Overflow 600 come menzionato.

Per gestire entità schedulabili multiple che necessitano eseguire simultaneamente il sistema operativo implementa la multielaborazione. I processi (o task nel sistema operativo in tempo reale rafforzato sicuro) sono threads di esecuzione indipendenti che contengono una sequenza di codice schedulabile in modo indipendente.

Queste entità, che costituiscono il sistema operativo in tempo reale rafforzato sicuro, possono competere in modo indipendente per il tempo di esecuzione della CPU a spese delle prestazioni (overhead di tempo e memoria). Each task ha la propria area dedicata di memoria volatile dove sono immagazzinati variabili locali, funzioni interne definite, registri e dati relativi a chiamate di funzione.

Quando lo schedulatore vuole commutare dall’esecuzione di un task all’esecuzione di un altro task, esso deve salvare il contesto del vecchio task e caricare il contesto del nuovo task. Il contesto di un task è l’insieme di registri che il task utilizza (contatore di programma, puntatore di stack, altri registri di lavorazione). In particolare uno di questi registri (il puntatore di stack) è un puntatore alla regione di stata utilizzata corrente. È essenziale per il corretto funzionamento del sistema assicurare che non vi sia interferenza tra diverse regioni di stack. Questo aspetto è importante dal punto di vista della sicurezza poiché le interferenze di stack sono notoriamente sovente veicoli di attacchi da parte di utenti malevoli.

Il controllo di integrità per le porzioni di codice e dati nella memoria non volatile non è sempre possibile per quanto riguarda la memoria volatile. I dati contenuti in queste porzioni di memoria sono continuamente modificati durante l’esecuzione dei processi e, quindi, piuttosto che verificare l’integrità dei dati, è preferibile controllare che le regioni di memoria utilizzate dai processi non superino i limiti prestabiliti.

In figura 6 è mostrato un registro di banco R dell’unità di elaborazione sicura 123 e la memoria RAM 121a. Nella memoria RAM 121a è mostrato uno stack SS comprendente uno stack di processo PSS ed uno stack principale MSS. come è noto, lo stack di processo o stack di tasche è tipicamente un’area di memoria di sistema preriservata che è utilizzata per indirizzi di ritorno, argomenti di procedura, registri temporaneamente salvati, e variabili localmente allocate. L’unità di elaborazione contiene tipicamente un registro, cioè registro di CPU R, che punta alla porzione superiore dello stack tramite un puntatore di stack STP.

Come mostrato, nello stack di processo MSS vi sono un primo stack SSA di un primo task TA ed un secondo stack SSB di un secondo task TB, che hanno una rispettiva dimensione di stack TSS, che definisce un corrispondente intervallo di stack all’interno dello stack di processo MSS. Come mostrato in figura, un’ultima porzione dell’intervallo di stack in entrambi nel primo stack SSA del primo task TA e nel secondo stack SSB del secondo task TB, corrispondente ad esempio agli ultimi 8/16 byte, presenta una configurazione o pattern di stack SP, che verrà spiegata facendo riferimento al diagramma di flusso di figura 11.

Durante le operazioni di task variabili il sistema operativo necessita di un modo per tenere traccia di quali task sono eseguiti utilizzando una tabella di task o schedulatore. Ad esso sono successivamente di richieste tre routine:

- eseguire la commutazione di contesto come mostrato in figura 6, i registri di task in uscita, cioè del primo task TA, presenti nella CPU, sono salvati nell’area di stack SSA del primo task TA e successivamente i registri di task in arrivo, cioè del secondo task TB, sono caricati dall’area di stack SSB del secondo task TB nei registri della CPU);

- inizializzare il sistema, aggiornare la macchina di stato e le strutture interne che compongono il sistema operativo in tempo reale sicuro;

- saltare al nuovo task, cioè secondo task TB.

Al fine di garantire l’integrità dei processi e dell’esecuzione del sistema, è necessario eseguire un meccanismo di controllo di overflow di task, cioè la procedura di Rilevamento di Stack Overflow 600, che verifica anche che il limite della regione di stack valida non sia stato sovrascritto, e che è rappresentato nel diagramma di flusso di figura 7.

In una fase 610 lo stack, ad es. SSA, SSB, allocato ad un task, ad es. TA, TB, è riempito con un noto pattern, il pattern di stack SP nel momento in cui il sistema e il sono stati inizializzati.

Successivamente, durante ogni commutazione di contesto, il sistema operativo controlla 620 una porzione finale, ad es. gli ultimi 8/16 byte, all’interno dell’intervallo di stack valido per assicurare che questo pattern rimanga immutato (non sia stato sovrascritto).

In una fase 630 la funzione di aggancio di stack overflow e richiamata se si verifica nella fase di test 620 che qualsiasi di questi byte di porzione finale dello stack siano cambiati dai loro valori originali. Tale funzione di aggancio di stack overflow intercetta l’anomalia e la rende evidente al sistema operativo che solleva un codice di errore 640 e che registra l’evento anomalo, cioè l’anomalia 650 analogamente alla fase 550, preferibilmente nello stesso registro SL.

La procedura 600 cattura, cioè solleva un errore e registra l’anomalia, la maggior parte delle occorrenze di stack overflow, sebbene sia concepibile che se ne potrebbero mancare alcune, ad es., dove si verifica uno stack overflow senza avere gli ultimi byte scritti.

Il sistema 10 è anche configurato per eseguire una procedura di rilevamento in tempo reale 700 al fine di garantire l’esecuzione nel tempo delle funzioni dell’HTA 12: tale procedura 700 monitora l’esecuzione del task e reagisce se il tempo supera il budget di tempo assegnato (tempo di esecuzione del caso peggiore).

Questo meccanismo controlla, così come il controllo di autenticità del runtime verifica su grandi scale di tempo che l’analisi di integrità sia stata eseguita, nel caso di piccole scale di tempo che tutte le funzioni di sicurezza mappate sui task HOS siano effettuate ed eseguite in tempo.

Al fine di garantire l’esecuzione del codice in tempo reale, durante l’analisi e progettazione del sistema, una durata di tempo massimo (budget di tempo) è stata assegnata a ciascun task, per consentire al sistema di schedulare i tasks e la non-violazione dei requisiti del tempo reale effettivo. La verifica di questi tempi di esecuzione è eseguita in tempo reale dal sistema durante l’esecuzione dei task ed una possibile violazione è rilevata e può dare adito ad operazioni correttive e di registrazione.

Un task periodico TK, definito tra il tempo in cui è pianificato per essere eseguito e il tempo di finitura/risposta, è definito da una tripletta di parametri, C, D, T dove C indica il tempo di esecuzione del caso peggiore (WCET) o budget di tempo di risorsa, cioè il tempo di calcolo, D è la relativa scadenza, cioè il tempo di scadenza, T è il periodo (periodo di tempo).

Considerando sistemi di task sporadici, dove vi è una pluralità di periodi tra due istanze di lavoro o job consecutive dello stesso task, un job che si verifica ad un certo tempo deve essere eseguito per al massimo C unità di tempo nell’intervallo di tempo prima della corrispondente scadenza D.

Un particolare caso di task sporadici sono quelli periodici per cui il periodo è l’esatta separazione temporale tra l’arrivo di due successivi job generati dal task.

Si distingue tra:

sistemi a scadenza implicita dove per ciascuna istanza la scadenza D corrisponde al periodo T;

sistemi a scadenza limitata dove per ciascuna istanza la scadenza D è inferiore uguale al periodo T;

sistemi a scadenza arbitraria dove non vi è limitazione tra la scadenza D ed il periodo T.

il sistema di elaborazione 10 è configurato per eseguire una procedura di rilevamento temporale 700 qui descritta facendo riferimento al diagramma di flusso in figura 8, in cui non vi è limitazione tra la scadenza D e il periodo, ma è eseguita una fase 710 di controllo della violazione per un task TK riguardante il tempo di esecuzione del caso peggiore del task generico C, dove il valore del tempo di esecuzione del caso peggiore C per una data istanza è fornito da un’analisi temporale off-line. In una fase 720 l’anomalia è registrata preferibilmente nello stesso registro di sicurezza SL.

Quindi dalla suddetta descrizione sono evidenti i vantaggi della soluzione descritta.

Il sistema descritto comprende in modo vantaggioso un sistema operativo in tempo reale rafforzato sicuro, dove il rafforzamento sicuro deriva dall’esecuzione di un controllo di autenticità o sul software del sistema operativo o sul software di applicazione al runtime, che è eseguito in tempo reale utilizzando una priorità alta in una maniera periodica e sfruttando un hardware dedicato per la crittografia e validazione di certificato.

In particolare il sistema qui descritto eseguendo la procedura di autenticazione in un task periodico che ha priorità più alta rispetto agli altri servizi host/HTA evita anche il fatto che un attaccante o un host troppo esigente, che chiede un grande numero di operazioni all’HTA, possa impedire al Controllo di Autenticità del Runtime di eseguire e rilevare la manomissione del software. Allo stesso tempo è evitato il fatto che il tempo per verificare l’intero flash superi un valore predefinito.

Naturalmente, senza pregiudizio per il principio delle forme di attuazione, i dettagli di costruzione e le forme di attuazione possono variare ampiamente rispetto a ciò che è stato qui descritto ed illustrato puramente a titolo di esempio, senza così discostarsi dall’ambito delle presenti forme di attuazione, come definito dalle seguenti rivendicazioni.

Claims (13)

1. RIVENDICAZIONI 1. Sistema di elaborazione configurato per eseguire operazioni trusted comprendente almeno un modulo di calcolo host (11) comprendendo un’unità di elaborazione host (113) e mezzi di memoria host (111,112) ed un hardware trust anchor (12), detto hardware trust anchor (12), che comprende una rispettiva unità di elaborazione sicura (123), un modulo di elaborazione hardware (122) dedicato ad un’operazione crittografica e mezzi di immagazzinamento sicuro (121), essendo configurati per immagazzinare ed eseguire un sistema operativo sicuro in tempo reale (HOS), detto sistema operativo sicuro (HOS) essendo configurato per eseguire un controllo di validità sul software che è utilizzato nel sistema di elaborazione (10) in cui detto sistema operativo sicuro (HOS) è configurato per eseguire un controllo di autenticità del runtime (500), che controlla l’integrità del codice software al runtime, detto controllo di autenticità del runtime (500) comprendente identificare (505) almeno blocchi software firmati (SSB) ed una corrispondente Intestazione (SSBH) e blocco di Dati (SSBD) residenti nella memoria del programma (121b) del detto hardware trust anchor (12) per l’esecuzione, ed eseguire, una prima fase (510) di controllo della validità di certificati (C) associati a detti blocchi software firmati (SSB), una seconda fase (520) di controllo della validità di un’intestazione (SSBH) di detto blocco software firmato (SBB), una terza fase (530) di controllo della validità di un hash dei dati (SSBD) di detti blocchi software firmati (SSB), e se una di dette fasi di controllo (510, 520, 530) di controlli della validità rileva un’anomalia, scrivere in un registro sicuro (SL) informazioni riguardanti l’anomalia rilevata, detto sistema operativo sicuro (HOS) essendo configurato per eseguire detto controllo di autenticità del runtime (500) in un task che ha la priorità più alta (PL) rispetto agli altri servizi host (11) o di hardware trust anchor (12).
2. 2. Sistema secondo la rivendicazione 1 in cui detto controllo di autenticità del runtime (500) è applicato anche ai blocchi software firmati (SSB) residenti in una memoria non volatile (111) dell’host (11).
3. 3. Sistema secondo la rivendicazione 1 o 2 in cui detto sistema operativo sicuro (HOS) è configurato per eseguire detto controllo di autenticità del runtime (500) in un task periodico con un dato periodo (T) che ha la priorità più alta (PL) rispetto agli altri servizi host (11) o di hardware trust anchor (12) e dette fasi di controllo (510, 520, 530) sono divise in una pluralità di sottofasi di durata configurabile (DH) che sono eseguite ad ogni periodo (T).
4. 4. Sistema secondo la rivendicazione 1, in cui detta prima fase (510) di controllo della validità di certificati (C) associati a detti blocchi software firmati (SSB) comprende il fatto che qualsiasi nuovo certificato da immagazzinare nell’hardware trust anchor (12) sia verificato con un altro certificato immagazzinato nell’hardware trust anchor (12), a meno che esso sia un certificato auto-firmato.
5. 5. Sistema secondo la rivendicazione 1, in cui detta seconda fase (520) di controllo della validità di un’intestazione (SSBH) di detto blocco software firmato (SSB) comprende verificare un campo di firma dell’intestazione del blocco software firmato (SBB) corrente.
6. 6.Sistema secondo la rivendicazione 1, in cui detta terza fase (530) di controllo della validità di un hash dei dati (SSBD) di detti blocchi software firmati (SSB) comprende calcolare un valore di hash su detto blocco di Dati (SSBD) in detto modulo di accelerazione hardware crittografica (122), in particolare tramite il motore di hash 122a, e confrontare detto valore di hash con i contenuti di un campo nell’intestazione (SSBH) che immagazzina un valore di hash che definisce un digest conforme calcolato sul blocco di Dati.
7. 7. Sistema secondo la rivendicazione 1, in cui detto sistema operativo è configurato per eseguire una procedura di Rilevamento di Stack Overflow (600) su uno stack (SS) di una memoria volatile (121a) dell’hardware trust anchor (12) utilizzata per l’esecuzione del task, comprendente controllare la quantità di stack utilizzato (SS) rispetto a limiti statici.
8. 8. Sistema secondo la rivendicazione 7, in cui detto sistema operativo (HOS) dell’hardware trust anchor (12) è configurato per riempire (610) un’area di stack allocata ad un task con un noto pattern (SP), durante ciascuna commutazione di contesto, controllare (620) un’ultima porzione all’inteno di un intervallo di stack valido per le modifiche richiamare (630) una funzione di aggancio di stack overflow se una modifica è rilevata rispetto all’operazione di riempimento.
9. 9. Sistema secondo la rivendicazione 1, in cui detto sistema operativo è configurato per eseguire una procedura di rilevamento in tempo reale (700) comprendente controllare (710) la violazione di un tempo di esecuzione del caso peggiore di un task (C), il valore del tempo di esecuzione del caso peggiore (C) per una data istanza del task essendo fornito da un’analisi temporale off-line e, se detta fase di controllo (710) rileva un’anomalia, scrivere in un registro sicuro (SL) informazioni riguardanti l’anomalia rilevata.
10. 10. Sistema secondo la rivendicazione 1, in cui detti almeno un’unità host (11) e hardware trust anchor (12) fanno parte di un Sistema su Chip, in particolare detto almeno un host (11) essendo un’ECU operante in un veicolo.
11. 11. Sistema secondo la rivendicazione 1, in cui detto scrivere in un registro sicuro (SL) informazioni riguardanti l’anomalia rilevata comprende creare un registro sicuro SL, comprendente informazioni riguardanti l’anomalia rilevata, o scrivere l’anomalia in detto registro sicuro (SL),
12. 12. Procedimento per eseguire operazioni trusted nel sistema di elaborazione secondo qualsiasi delle rivendicazioni 1 a 10, comprendente immagazzinare ed eseguire un sistema operativo in tempo reale sicuro (HOS) che esegue un controllo di validità sul software che è utilizzato nel sistema di elaborazione, detto procedimento comprendendo eseguire un controllo di autenticità del runtime (500), che controlla l’integrità del codice software al runtime, detto controllo di autenticità del runtime (500) comprendendo identificare (505) in blocco firmato software (SSB) ed una corrispondente Intestazione (SSBH) e blocco di Dati (SSBD) residenti almeno in una memoria di programma (121b) dell’hardware trust anchor (12) per l’esecuzione, ed eseguire per ciascun blocco firmato software (SSB), una prima fase (510) di controllo della validità di certificati (C) associati a detti blocchi software firmati (SSB), una seconda fase (520) di controllo della validità di un’intestazione (SSBH) di detto blocco software firmato (SBB), una terza fase (530) di controllo della validità di un hash dei dati (SSBD) di detti blocchi software firmati (SSB), e se una di dette fasi di controllo (510, 520, 530) di controlli della validità rileva un’anomalia, scrivere in un registro sicuro (SL) informazioni riguardanti l’anomalia rilevata, detto sistema operativo sicuro essendo configurato per eseguire detto controllo di autenticità del runtime (500) in un task che ha la priorità più alta (PL) rispetto agli altri servizi host (11) o di hardware trust anchor (12).
13. 13. Procedimento secondo la rivendicazione 10, in cui detto procedimento comprende le operazioni del sistema secondo qualsiasi delle rivendicazioni 2 a 11.