IT201900015827A1

IT201900015827A1 - Dispositivo sicuro operante con una piattaforma sicura resistente alla manomissione, corrispondente sistema e prodotto informatico

Info

Publication number: IT201900015827A1
Application number: IT102019000015827A
Authority: IT
Inventors: Amedeo Veneroso; Nieuwenhuyze Olivier Van
Original assignee: St Microelectronics Srl; Proton World Int Nv
Priority date: 2019-09-06
Filing date: 2019-09-06
Publication date: 2021-03-06
Also published as: EP3789902A1; US11514197B2; US20210073425A1; CN112464222A; EP3789902C0; EP3789902B1

Description

DESCRIZIONE dell’invenzione industriale dal titolo:

“Dispositivo sicuro operante con una piattaforma sicura resistente alla manomissione, corrispondente sistema e prodotto informatico”

TESTO DELLA DESCRIZIONE

Campo Tecnico

Le forme di attuazione della presente descrizione sono relative a soluzioni concernenti un dispositivo sicuro operante con una piattaforma sicura resistente alla manomissione che comprende una piattaforma hardware resistente alla manomissione e una piattaforma primaria virtuale operante con un sistema operativo di basso livello che effettua un’astrazione delle risorse della piattaforma hardware, e una piattaforma secondaria con un sistema operativo di alto livello che fornisce un’astrazione ulteriore delle risorse ad applicazioni in cui sono incorporati (“embedded”) rispettivi host interni, detto dispositivo sicuro comprendendo un dominio di host interno che comprende detti host, detto dispositivo sicuro comprendendo una pluralità di interfacce di ingresso/uscita logiche e/o fisiche attraverso le quali host esterni possono accedere a detti host interni, detta piattaforma primaria virtuale essendo configurata per impostare canali di comunicazione logici aventi come estremità detti host esterni e detti host interni.

Forme di attuazione della presente descrizione sono relative in particolare a un dispositivo di Piattaforma Sicura Intelligente (SSP, “Smart Secure Platform”) integrato o incorporato, ossia embedded, che comprende elementi sicuri per applicazioni nel campo dei trasporti, dei pagamenti, del controllo degli accessi, delle chiavi digitali per automotive, delle eSIM, dei servizi sicuri, dell’identità come ePassport o eID o patente di guida mobile o altri servizi digitali che richiedono un livello di sicurezza elevato per memorizzare un loro bene (loro beni) e/o una loro credenziale (loro credenziali).

Sfondo

Le SSP (Smart Secure Platform) Embedded e Integrate sono una nuova classe di dispositivi attualmente in corso di specifica nell’ETSI, come indicato per esempio in ETSI TS 103 465 V15.0.0 (2019-05). Dal punto di vista dell’hardware una SSP Embedded è un chip autonomo (“standalone”) e una SSP integrata è un chip isolato, integrato in una CPU più grande, che può essere usata per fare convergere servizi da differenti elementi sicuri esistenti.

Attualmente, ci sono vari elementi sicuri nei telefoni di fascia alta, che sono in qualche modo simili, come un elemento sicuro che lavora congiuntamente a un ambiente di esecuzione fidato (TEE, “Trusted Execution Environment”) di un Telefono Mobile per memorizzare le password e i segreti, Elementi Sicuri embedded NFC (Near Field Communication) per i pagamenti NFC, la eUICC, cioè la Carta a Circuito Integrato Universale embedded (“embedded Universal Integrated Circuit Card”) usata come elemento sicuro per l’autenticazione nelle telecomunicazioni mobili.

I vari chip autonomi fisici corrispondenti sono basati tipicamente su sistemi operativi e hardware simili, che hanno requisiti e caratteristiche simili, ma non identici. Questo conduce alla necessità della convergenza di tali dispositivi sicuri simili in uno singolo. Tuttavia, è risultato che un singolo sistema operativo è troppo complesso per gestire tutti i requisiti, in particolare nei termini delle certificazioni, come per l’approvazione e le applicazioni di pagamento. Per esempio, è necessario che un Elemento Sicuro embedded (eSE, “embedded Secure Element”) NFC sia certificato da Visa, Master Card, EMVco e altri. Invece, è necessario che un elemento sicuro per telecomunicazioni, come l’eUICC, sia testato da molti Operatori di Rete Mobile.

Così, al fine di separare i differenti requisiti di sistema operativo anche se è usato un singolo Secure Element (o TRE), è noto il fatto di adottare un approccio basato su un dispositivo sicuro operante con una Smart Secure Platform, o piattaforma sicura smart, (SSP), in particolare comprendente una piattaforma primaria virtuale (VPP, “Virtual Primary Platform”).

Nella Figura 1, è rappresentata un’architettura di una piattaforma sicura smart 10, che rappresenta un elemento resistente alla manomissione (TRE, “Tamper Resistant Element”), che comprende una piattaforma hardware 11 e una piattaforma primaria 1P, attuata specificamente da una Piattaforma Primaria Virtuale 12 o VPP. In effetti, la VPP 12, come descritto per esempio in GlobalPlatform Technology VPP – Concepts and Interfaces, Versione 1.0.1 reso disponibile dal consorzio GlobalPlatform all’URL https://globalplatform.org/specs-library/globalplatformtechnology-virtual-primary-platform-v1-0-1/, comprende un sistema operativo di basso livello (LLOS, “Low Level Operating System”) che gestisce le funzioni hardware relative alla sicurezza e servizi e capacità di microelaborazione nativi, che gestiscono le funzioni hardware relative alla comunicazione e alla gestione del firmware. Nella Figura 1, un blocco 12 si riferisce sostanzialmente al LLOS. La VPP 12 comprende anche un blocco indicato con 12a che comprende un’Interfaccia Binaria per Applicazioni (ABI, “Application Binary Interface”) relativa all’implementazione del LLOS, al fine di mappare una qualsiasi Interfaccia per la Programmazione di Applicazioni (API, “Application Programming Interface”), che dipendono dal linguaggio di programmazione reso disponibile su un sistema operativo di alto livello o HLOS (High Level Operating System), che è in una piattaforma secondaria 2P accompagnato da rispettive applicazioni di Piattaforma Virtuale Primaria o applicazioni di VPP 14. L’HLOS è un Programma aggiuntivo compreso in un’Applicazione di VPP, che fornisce un’astrazione ulteriore delle risorse e dei servizi alle sue applicazioni di HLOS 14. Uno stesso HLOS può supportare varie Applicazioni di VPP 14. Il LLOS nel blocco 12 è eseguito in modalità di CPU privilegiata ed è minimo, contenendo soltanto le funzionalità che non possono essere eseguite in modalità di CPU non privilegiata. Il LLOS comprenderà un kernel, cioè un blocco 12a, che supporta la gestione di Processi multipli e, oltre a un kernel, il LLOS supporterà:

- il Programma di Bootstrap iniziale della Piattaforma Primaria

-la gestione di tutte le funzioni hardware seguenti: o Funzioni di Sicurezza,

o Funzioni di Gestione della Memoria,

o Funzioni di Trasferimento in Memoria,

o Funzioni di Sistema.

Così, il LLOS nel blocco 12 virtualizza le risorse hardware sottostanti, cioè rappresenta un’astrazione delle risorse, e comprende una rispettiva API di VPP che interagisce con applicazioni di VPP 14 multiple.

Sullo stesso livello, è anche rappresentato che la piattaforma secondaria 2P delle applicazioni di VPP 14 comprende un modulo di loader del firmware 13, che è specificamente il Loader del Firmware Aperto (OFL, “Open Firmware Loader”) di GlobalPlatform nell’esempio, che standardizza come il firmware può essere caricato e gestito nella piattaforma hardware resistente alla manomissione 11, dove una piattaforma VPP 12 GlobalPlatform definisce i servizi di sicurezza per la piattaforma hardware resistente alla manomissione 11 nella piattaforma primaria 1P.

La Piattaforma Hardware 11 è implementata in un TRE e può integrare:

- una o più CPU, che saranno costruite specificamente per un livello elevato di sicurezza

- una memoria ad accesso casuale (RAM, “Random Access Memory”)

- una memoria non volatile (NVM, “Non-Volatile Memory”) di tipi potenzialmente differenti (riprogrammabili oppure no)

- una Funzione di Generatore di Veri Numeri Casuali - un dispositivo di memorizzazione di credenziali a lungo termine

- funzioni di sicurezza (per es., sensori)

- una funzione di Protezione di Chiave per limitare l’accesso della CPU a un materiale con chiave segreta

- una Funzione di Gestione della Memoria incaricata di tradurre gli indirizzi fisici della memoria in virtuali

- indirizzi della memoria e protezione degli spazi di memoria secondo i loro diritti di accesso.

La piattaforma hardware 11 dovrebbe integrare inoltre: - Funzioni Crittografiche

- una Funzione di Trasferimento in Memoria (per es., un controllore di accesso diretto in memoria (“Direct Memory Access”)).

Anche se la piattaforma VPP è molto efficace nell’isolare i requisiti del sistema operativo, ha un inconveniente nell’impatto sull’arresto del dispositivo. In effetti, per affrontare le applicazioni delle varie VPP, è richiesto un “protocollo di indirizzamento”, che consente di indirizzare le varie applicazioni di VPP all’interno. Tale protocollo definito nella VPP è chiamato protocollo di rete di VPP, come specificato per esempio in GlobalPlatform Technology Virtual Primary Platform – Network Protocol, Versione 1.0.1.

Il protocollo di rete di VPP può impostare delle “pipe”, ossia condotte di dati, cioè un circuito di dati logico che instrada il canale o canali di comunicazione a pacchetto tra due gate di due host differenti all’interno di due domini di host differenti, con un modem, un EE Ricco (REE, “Rich EE”), un EE Fidato (“Trusted EE”) e altri host. Un gate è un punto di entrata della pipe verso un servizio/applicazione che è operato all’interno di un host, che è a sua volta un’entità logica che opera uno o più gate.

Tale impostazione delle pipe consente una multiplazione di protocolli sulla stessa interfaccia fisica.

Nella Figura 2, è rappresentata schematicamente una rete che comprende un dominio di host TRE 23, comprendente un qualsiasi host embedded in un’Applicazione di VPP 14 nella piattaforma hardware 11 a elementi resistenti alla manomissione hardware e domini di host esterni 30 comprendenti:

- un Dominio di Host TEE 31 per un gruppo di Host 311, 312 in un Ambiente di Esecuzione Fidato, - un Dominio di Host MBM 33 per il gruppo di Host 331 in esecuzione sul Modem a Banda Larga Mobile (“Mobile Broadband Modem”),

- un dominio di Host REE 32 per il gruppo di Host 321, 322, 323 sull’Ambiente di Esecuzione Ricco (“Rich Execution Environment”).

Sono rappresentate le pipe P che connettono i gate dell’Host TRE 231 nel dominio di host TRE 23 ai gate degli host nei domini di host esterni 31, 32, 33.

Oltre a ciò, può essere richiesto che le interfacce legacy siano limitate a specifiche classi di applicazioni di VPP per motivi di sicurezza.

In particolare, in specifici dispositivi, è necessario che l’elemento sicuro acceda ai pin di GPIO (General Input Output ports) per controllare gli ingressi dell’utente e per eseguire altre funzioni.

In specifiche applicazioni, c’è anche il requisito di limitare la visibilità dei pin di GPIO a specifiche applicazioni di VPP.

Sintesi

In base alla descrizione precedente, si sente la necessità di soluzioni che superino uno o più degli inconvenienti delineati precedentemente.

Secondo una o più forme di attuazione, tale scopo è raggiunto attraverso dispositivi aventi le caratteristiche esposte specificamente nelle rivendicazioni che seguono. Le forme di attuazione concernono inoltre un relativo procedimento per gestire l’accesso ad host così come un relativo prodotto informatico corrispondente, caricabile nella memoria di almeno un elaboratore e comprendente porzioni di codice software per eseguire le fasi del procedimento quando il prodotto è eseguito su un elaboratore. Come usato qui, un riferimento a un tale prodotto informatico intende essere equivalente a un riferimento a un mezzo leggibile da elaboratore che contiene istruzioni per controllare un sistema di elaborazione al fine di coordinare l’esecuzione del procedimento. Un riferimento ad “almeno un elaboratore” intende evidentemente evidenziare la possibilità che la presente descrizione sia implementata in una forma modulare e/o distribuita.

Le rivendicazioni sono parte integrante dell’insegnamento tecnico qui fornito della descrizione.

Come menzionato in precedenza, la presente descrizione fornisce soluzioni per quanto riguarda un dispositivo sicuro operante con una piattaforma sicura resistente alla manomissione che comprende una piattaforma hardware resistente alla manomissione e una piattaforma primaria virtuale operante con un sistema operativo di basso livello che effettua un’astrazione delle risorse della piattaforma hardware, e una piattaforma secondaria con un sistema operativo di alto livello che fornisce un’astrazione ulteriore delle risorse ad applicazioni in cui sono embedded rispettivi host interni, detto dispositivo sicuro comprendendo un dominio di host interno che comprende detti host interni,

detto dispositivo sicuro comprendendo una pluralità di interfacce di ingresso/uscita logiche e/o fisiche attraverso le quali host esterni possono accedere a detti host interni,

detta piattaforma primaria virtuale essendo configurata per impostare interazioni tra detti host esterni e detti host interni,

in cui

detto dominio di host interno comprende un insieme ulteriore di host virtuali, ciascuno configurato per operare come un proxy tra un’interfaccia di ingresso/uscita e un’applicazione, ciascuna interfaccia di ingresso/uscita essendo configurata per indirizzare soltanto uno tra gli host virtuali.

In varianti di forme di attuazione, detto dispositivo sicuro è configurato per effettuare un filtraggio che comprende di selezionare specifici host virtuali atti a impostare un’interazione con un host interno embedded in una specifica applicazione e viceversa.

In varianti di forme di attuazione, dette interazioni comprendono canali di comunicazione logici aventi come estremità detti host esterni e detti host interni.

In varianti di forme di attuazione, detto filtraggio comprende di selezionare specifici host virtuali atti a impostare un canale di comunicazione logico con un host interno embedded in una specifica applicazione e viceversa.

In varianti di forme di attuazione, detto filtraggio comprende di accedere a una whitelist (“whitelist”) in base a un identificatore di famiglia di firmware.

In varianti di forme di attuazione, detta whitelist è caricata con il caricamento del firmware.

In varianti di forme di attuazione, detto identificatore di famiglia di firmware è ottenuto da un descrittore dell’applicazione.

In varianti di forme di attuazione, detto identificatore di famiglia di firmware è un descrittore di UUID.

In varianti di forme di attuazione, detto dispositivo è un dispositivo di Piattaforma Sicura Intelligente embedded e detta piattaforma primaria virtuale è una Piattaforma Primaria Virtuale GlobalPlatform.

In varianti di forme di attuazione, detto dispositivo è configurato per verificare l’autorizzazione di una richiesta di identificazione di una famiglia di firmware specifica per un firmware specifico durante il caricamento del firmware, in particolare implementato dal TRE o un suo loader.

La presente descrizione fornisce anche soluzioni per quanto riguarda un procedimento per gestire l’accesso tra host interni e un host esterno in un dispositivo sicuro, impostando interazioni tra detti host esterni e detti host interni, in particolare canali di comunicazione logici aventi come estremità host esterni e host interni, secondo una qualsiasi delle rivendicazioni precedenti, comprendente aggiungere a detto dominio di host interno un insieme ulteriore di host virtuali, ciascuno configurato per operare come un proxy tra un’interfaccia di ingresso/uscita e un’applicazione, indirizzando con ciascuna interfaccia di ingresso/uscita soltanto uno tra gli host virtuali.

In varianti di forme di attuazione, il procedimento comprende di filtrare, selezionando specifici host virtuali atti a interagire con un host interno embedded in una specifica applicazione e viceversa.

In varianti di forme di attuazione, il procedimento comprende di filtrare comprende di registrare una whitelist degli host virtuali per una data applicazione durante il caricamento del firmware di detta applicazione.

In varianti di forme di attuazione, il detto impostare canali di comunicazione logici aventi come estremità detti host esterni e detti host interni imposta detti canali di comunicazione logici come comprendenti detti host virtuali selezionando le estremità in base alla configurazione di proxy degli host virtuali e ai criteri di selezione specificati in detta fase di filtraggio, in particolare da detta fase di registrazione di una whitelist degli host virtuali per una data applicazione durante il caricamento del firmware di detta applicazione.

La presente descrizione fornisce anche soluzioni per quanto riguarda un prodotto informatico che può essere caricato nella memoria di almeno un processore e che comprende porzioni di codice software per implementare il procedimento secondo una qualsiasi delle precedenti forme di attuazione del procedimento.

Breve descrizione delle figure

Forme di attuazione della presente descrizione saranno ora descritte con riferimento ai disegni annessi, che sono forniti a puro titolo di esempio non limitativo, e nei quali:

- le Figure 1 e 2 sono già state descritte in precedenza;

- la Figura 3 rappresenta uno schema a blocchi che illustra una forma di attuazione del procedimento qui descritto;

- la Figura 4 rappresenta un diagramma di flusso che illustra operazioni di una forma di attuazione del procedimento qui descritto.

Descrizione Dettagliata

Nella descrizione che segue, sono illustrati numerosi dettagli specifici, allo scopo di fornire una comprensione approfondita di forme di attuazione. Le forme di attuazione possono essere attuate senza uno o più dei dettagli specifici o con altri procedimenti, componenti, materiali, ecc. In altri casi, operazioni, materiali o strutture ben note non sono illustrate o descritte in dettaglio per evitare di rendere poco chiari gli aspetti delle forme di attuazione.

Un riferimento a “una forma di attuazione” nel quadro della presente descrizione intende indicare che una particolare configurazione, struttura, o caratteristica descritta con riferimento alla forma di attuazione è compresa in almeno una forma di attuazione. Per cui, le frasi come “in una forma di attuazione” che compaiono in vari punti della presente descrizione non fanno necessariamente riferimento tutte alla stessa forma di attuazione. Inoltre, particolari conformazioni, strutture o caratteristiche possono essere combinate in un modo adeguato qualsiasi in una o più forme di attuazione.

I riferimenti usati qui sono forniti semplicemente per convenienza e non definiscono l’ambito o il significato delle forme di attuazione.

Nelle figure, parti, elementi o componenti che sono già stati descritti con riferimento alle Figure da 1 a 4 sono indicati con gli stessi riferimenti usati precedentemente in tali Figure; la descrizione di tali elementi descritti precedentemente non sarà ripetuta in seguito al fine di non sovraccaricare la presente descrizione dettagliata.

La soluzione qui descritta prevede sostanzialmente di aggiungere nel dominio di host dell’elemento resistente alla manomissione una pluralità di host virtuali associati alle interfacce di ingresso/uscita dell’elemento resistente alla manomissione, essendo fornito anche un meccanismo di filtraggio degli host virtuali atti a interagire con un host interno embedded in una specifica applicazione, cioè un’istanza di firmware, eseguito nell’elemento resistente alla manomissione, e viceversa.

A questo riguardo, nella Figura 3 è rappresentato un diagramma schematico che rappresenta un dominio di host 23, che rappresenta il dominio di host di TRE, che può corrispondere al dominio di host del dispositivo di Piattaforma Sicura Intelligente 10 o Smart Secure Platform, e che è rappresentativo di host interni, integrati in un’applicazione che è eseguita nel dispositivo di Piattaforma Sicura Intelligente 10, specificamente un’applicazione di VPP. Un’applicazione di VPP è un’istanza di un firmware su un VPP 12. Il suo uso dipende dai casi e può eseguire un Sistema Operativo di Alto Livello (HLOS), cioè un programma aggiuntivo compreso in un’Applicazione di VPP, che fornisce un’ulteriore astrazione, cioè strato di interfaccia, delle risorse dei servizi alla sua applicazione o alle sue applicazioni di HLOS, e tale applicazione o tali applicazioni di HLOS. Nel dominio di host 23 sono rappresentate le applicazioni di VPP 141, 142 che integrano rispettivi host.

Quindi, nella Figura 3, sono rappresentati host esterni 331 e 341, che sono interfacciati al dominio di host 23 del dispositivo di Piattaforma Sicura Intelligente 10 da interfacce esterne 25, specificamente un’interfaccia di ISO 251 e un’interfaccia di GPIO 252.

L’host esterno 331 corrisponde a un modem, cosicché corrisponde a un host del dominio di host 33 del Modem a Banda Larga Mobile, al quale la prima applicazione di VPP 141 accede attraverso l’interfaccia di ISO 251 e viceversa. L’host esterno 342 corrisponde a un pulsante, per es. il pulsante di Sign-In Google, in altre parole un ingresso di controllo che accede alla seconda applicazione di VPP 141 attraverso l’interfaccia di GPIO 252 e viceversa. Così, la piattaforma primaria virtuale 12 è configurata per impostare interazioni tra gli host esterni e gli host interni. A titolo di esempio di tali interazioni, sono impostate pipe aventi come estremità detti host esterni e detti host interni. In altre parole, sono impostate rispettive pipe, come menzionato viste come un circuito di dati logico che instrada un canale di comunicazione a pacchetto tra due gate di due host differenti, in questo caso in relazione alle applicazioni di VPP 141, 142 e agli host 31, 32, all’interno di due domini di host differenti, cioè il dominio di host 23 del dispositivo di Piattaforma Sicura Intelligente 10 e il dominio di host esterno degli host esterni 331, 341. Secondo la soluzione qui descritta, ciò è ottenuto comprendendo negli host virtuali 24 delle pipe, interfacce esterne 25, che sono configurate per gestire gli host esterni 331, 341. Così, una prima pipe è rappresentata dagli elementi 331, 241, 251, 141 e una seconda pipe è rappresentata dagli elementi 341, 242, 252, 142.

Secondo la soluzione qui descritta, in ciascuna pipe ciascuna singola porta di ingresso/uscita, cioè interfaccia esterna 25, indirizza un host virtuale 24 all’interno del dominio di host di TRE 23. Su ciascuna porta di ingresso/uscita, non c’è alcuna possibilità di usare un meccanismo di indirizzamento se connessa a dispositivi legacy.

Come rappresentato, il LLOS della VPP 12 ha aggiunti al suo dominio di host 23 host virtuali 24, ciascuno di loro essendo configurato per operare come un proxy di un’interfaccia di ingresso/uscita esterna fisica 25, cioè agisce come un intermediario per le richieste o le connessioni di interfacce di ingresso/uscita esterne fisiche 25. L’host virtuale 24 è quindi configurato per dirigere la connessione dall’interfaccia esterna 25 ed è diretto quindi a una specifica Applicazione di VPP 14. In varianti di forme di attuazione, possono anche essere definiti domini di host virtuali e gli host virtuali 24 possono anche essere assegnati a un dominio o anche a domini di host virtuali multipli.

Secondo la soluzione qui descritta, il dispositivo sicuro 10 è anche configurato per implementare un meccanismo di filtraggio, selezionando gli host virtuali 24 atti a interagire con un dato host interno 23 integrato in una specifica applicazione 14 e viceversa.

Un tale meccanismo di filtraggio sfrutta preferibilmente un meccanismo di whitelisting, cioè che consente esplicitamente ad alcuni host virtuali 24 di accedere a uno specifico host interno 23; in particolare, può sfruttare il whitelisting implementato nella VPP 12 in un protocollo di rete virtuale, come descritto in Virtual Primary Platform – Network Protocol – Public Release v1.0.

La rete comporta una raccolta di domini di host, un raggruppamento di host, come già descritto, secondo perimetri funzionali, come il Dominio di Host di TRE, gli host, un host controllore di rete e un router, che instrada pacchetti in pipe tra gli host sotto il controllo dell’host controllore di rete. In questo contesto, una rete valida è una raccolta di almeno due host che sono connessi insieme logicamente e sono connessi fisicamente attraverso il router con il quale l’host ha una pipe statica.

Il router è configurato per mantenere due liste bianche separate, per ciascun host, per filtrare l’accesso all’host in base a un identificatore di host e a un identificatore di dominio di host. Il router instrada i pacchetti soltanto da un host a un altro se l’identificatore dell’host sorgente è nella whitelist degli host dell’host destinazione e se l’identificatore del dominio di host sorgente dell’host sorgente è nella whitelist dei domini di host dell’host destinazione. Una whitelist vuota impedisce all’host di ricevere qualunque pacchetto da un qualsiasi altro host.

Così, la VPP 12 è allora configurata per identificare una whitelist WL di host virtuali ulteriore di applicazioni di VPP al momento del caricamento di un firmware da parte del modulo di OFL 13, per es. registrando tale whitelist di WL host virtuali ulteriore con l’Host Controllore di Rete della VPP al momento del caricamento del firmware, in un modo simile a quello della procedura come descritto nella Figura 6.1.3 di Virtual Primary Platform – Network Protocol – Public Release v1.0.1, per le altre liste bianche di host e di domini di host.

Nell’applicazione di VPP 14, il descrittore dell’applicazione comprende identificatori del tipo di Identificatore Univoco Universale (UUID, “Universal Unique Identifier”), tra i quali l’Identificatore di Famiglia di Firmware (“Family Firmware Identifier”), che identifica che un particolare Firmware appartiene a una particolare classe di Firmware. Tale UUID può essere usato come un campo che identifica l’applicazione 14 in una whitelist relativa. Per esempio, una whitelist WL può indicare ciò che segue:

- per un’applicazione di VPP di eUICC, identificata dall’Identificatore di Famiglia di Firmware di eUICC, nell’insieme delle applicazioni 14, l’host virtuale 25 con cui può interagire è l’host virtuale di ISO;

- per un’applicazione di VPP di eSE, identificata dall’Identificatore di Famiglia di Firmware di eSE, nell’insieme 14 di applicazioni, l’host virtuale 25 con cui può interagire è l’host virtuale di CLF (Contactless Front End)

- per un’applicazione di VPP di TEE companion, identificata dall’Identificatore di Famiglia di Firmware di eSE, nell’insieme 14 di applicazioni, l’host virtuale 25 con cui può interagire è l’host virtuale di GPIO

Così, la whitelist può essere vista come una tabella, in particolare una tabella di ricerca (“look-up table”), alla quale si accede con un identificatore dell’applicazione di VPP 14 e che restituisce la lista di host virtuali 25 associati a tale applicazione di VPP 14, che deve operare come proxy per l’interfaccia esterna 25 associata in modo univoco a essa.

Come appena indicato, l’UUID può essere per esempio l’Identificatore di Famiglia di Firmware definito in OFL. Nel caso di applicazioni 14 che devono accedere a comandi o controllare ingressi di utente, come il pulsante 32, o per limitare l’accesso di GPIO a una specifica applicazione 14, può essere definito un nuovo Identificatore di Famiglia di Firmware (per es., Family_HWController). La whitelist corrispondente all’Identificatore di Famiglia di Firmware Family_HWController per quell’identificatore contiene l’Host Virtuale Gestore di GPIO, 252. Tutte le altre liste bianche devono essere configurate in modo che sia impedito che comunichino con esso, cioè non includono l’Host Virtuale Gestore di GPIO, 252, come host esterno accessibile.

L’Identificatore di famiglia, come rappresentato nello standard di VPP, è un numero scritto nel firmware che ha due impatti:

• L’Identificatore di famiglia imposta la whitelist dell’Applicazione di VPP 14

• L’Identificatore di famiglia identifica l’ecosistema che consente lo scaricamento di un’applicazione di VPP; per es., per identificatori di famiglie per Telecom, sono usati i certificati e l’ecosistema GSMA.

Come esempio, un Identificatore di Famiglia di Firmware può avere UUID form:= NID is [OEM domain.name] o NID is [SDO domain.name] e l’NSS è il nome della Famiglia di Firmware.

Il NID indica l’identificatore, OEM domain.name è il Nome di Dominio Qualificato Completamente (FQDN, “Fully Qualified Domain Name”) dell’azienda o dell’OEM (Original Equipment Manufacturer) che definisce l’host 23 dell’applicazione 14, per esempio il nome di dominio di un’azienda di telecomunicazioni, [SDO domain.name] definisce il FQDN di un’organizzazione di sviluppo di standard o di un forum dell’industria, come GlobalPlatform (globalplatform.org). Il NSS è il nome del Caso d’Uso, per es. “servizio di entrata senza chiave”.

Così, come rappresentato nel diagramma di flusso della Figura 4, che rappresenta una forma di attuazione del procedimento qui descritto, dato un dispositivo sicuro 10 operante con una piattaforma sicura resistente alla manomissione che comprende una piattaforma hardware resistente alla manomissione 11 e una piattaforma primaria virtuale 12 operante con un sistema operativo di basso livello che effettua un’astrazione delle risorse della piattaforma hardware 11, e una piattaforma secondaria 2P con un sistema operativo di alto livello che fornisce un’astrazione ulteriore delle risorse ad applicazioni 14 in cui sono embedded rispettivi host interni 23, detto dispositivo sicuro 10 comprendendo un dominio di host interno 23 che comprende detti host interni 23, detto dispositivo sicuro 10 comprendendo una pluralità di interfacce di ingresso/uscita 25, che possono essere interfacce fisiche e/o logiche, attraverso le quali host esterni 311, 341 possono accedere a detti host interni 23, un procedimento 500 per gestire l’accesso tra host interni e un host esterno impostando canali di comunicazione logici P aventi come estremità detti host esterni, per es. 311, 341 e detti host interni 23, comprende le fasi di fornire 510 un insieme ulteriore di host virtuali 24, ciascuno configurato per operare come un proxy tra un’interfaccia di ingresso/uscita 25 e un’applicazione 14, ciascuna interfaccia di ingresso/uscita 25 indirizzando soltanto uno tra gli host virtuali 24,

filtrare 520, selezionando specifici host virtuali 25 atti a interagire con un host interno 23 embedded in una specifica applicazione 14 e viceversa.

Detta fase di filtraggio, in una forma di attuazione preferita, comprende una fase 525 di registrazione di una whitelist WL degli host virtuali per una data applicazione durante il caricamento del firmware di detta applicazione. Tale caricamento del firmware può avere luogo prima o dopo una fase 110 di fornitura di un insieme ulteriore di host virtuali 24. Il procedimento 500 della Figura 4 può comprendere una fase specifica di fornitura di tale dispositivo sicuro 10 prima della fase 510 di fornitura degli host virtuali 23.

Per esempio, il comando SET WHITELIST (specificamente LINK_SET_HOST_WHITELIST secondo il Par. 5.3.2.5 di GlobalPlatform Technology Virtual Primary Platform – Network Protocol Version 1.0.1.) può essere impartito (o ricevuto) dall’applicazione di VPP 141. La soluzione qui descritta prevede che il protocollo di rete virtuale intercetti il comando SET WHITELIST e che lo filtri oppure no a seconda della configurazione della whitelist; quindi, è applicato il tradizionale meccanismo di whitelist dal protocollo di rete virtuale di VPP.

Come rappresentato nella Figura 1, il procedimento 500 per gestire l’accesso tra host interni e un host esterno, in seguito alle fasi imposta infine i canali di comunicazione logici P in una fase 530. Tale fase di impostazione dei canali di comunicazione logici P aventi come estremità detti host esterni 311, 341 e detti host interni 23 imposta tali canali di comunicazione logici comprendendo gli host virtuali 25 forniti nella fase 510, selezionando le estremità in base alla configurazione di proxy degli host virtuali e ai criteri di selezione specificati nella fase di filtraggio 520, in particolare mediante la fase di whitelisting 125, registrando una whitelist degli host virtuali per una data applicazione durante il caricamento del firmware di detta applicazione.

In varianti di forme di attuazione, il dispositivo qui descritto può essere configurato per verificare l’autorizzazione di una richiesta di identificazione di una famiglia di firmware specifica per un firmware specifico durante il caricamento del firmware, a titolo di esempio implementato dal TRE o un suo loader.

La forma di attuazione appena descritta consente, in particolare in confronto all’eSSP, un impatto limitato o nessun impatto sui componenti del terminale (“handset”) e il supporto di un’associazione delle interfacce fisiche con le applicazioni di VPP. Inoltre, la soluzione consente di usare l’applicazione di VPP per isolare i servizi gli uni rispetto agli altri.

Fermi restando i principi di fondo, i dettagli e le forme di attuazione possono variare, anche in modo apprezzabile, rispetto a quanto è stato descritto e illustrato qui, puramente a titolo di esempio, senza uscire con ciò dall’ambito della presente invenzione, come definito dalle rivendicazioni che seguono.

Il meccanismo di filtraggio può essere differente dal meccanismo di whitelist. Per esempio, per filtrare gli host virtuali atti a interagire con un host interno embedded in una specifica applicazione eseguita nell’elemento resistente alla manomissione, può essere implementato un meccanismo di blacklisting o il whitelisting può essere implementato senza alcuna relazione con la whitelist di VNP o con l’Identificatore di Famiglia.

L’insieme di interfacce esterne 25 può includere interfacce fisiche e/o logiche, siccome la soluzione qui descritta può essere applicata anche quando host multipli condividono un’interfaccia fisica che ha in aggiunta qualche gestione logica. Per esempio, può essere usato il protocollo SWP (Single Wire Protocol) per connettersi sia a un router NFC, sia a un processore di applicazione. Ciò può essere gestito con due pipe differenti sopra il protocollo di VNP che sono inoltrate entrambe sullo stesso collegamento fisico (SWP), ma su due canali logici differenti sull’SWP, chiamate pipe di Interfaccia di Controllore Host o HCI (Host Controller Interface).

In varianti di forme di attuazione, la piattaforma primaria virtuale è configurata per impostare interazioni tra detti host esterni e detti host interni, il che può comprendere che un pin sia usato soltanto per la trasmissione dei segnali, per es. il valore sul pin potrebbe essere soltanto uno zero logico o un uno logico, o Set e Reset.

Claims

RIVENDICAZIONI 1. Dispositivo sicuro (10) operante con una piattaforma sicura resistente alla manomissione che comprende una piattaforma hardware resistente alla manomissione (11) e una piattaforma primaria virtuale (12, 1P) operante con un sistema operativo di basso livello che effettua un’astrazione delle risorse della piattaforma hardware (11), e una piattaforma secondaria (2P) con un sistema operativo di alto livello che fornisce un’astrazione ulteriore delle risorse ad applicazioni (14) in cui sono incorporati rispettivi host interni (23), detto dispositivo sicuro (10) comprendendo un dominio di host interno (23) che comprende detti host interni (23), detto dispositivo sicuro (10) comprendendo una pluralità di interfacce di ingresso/uscita logiche e/o fisiche (25) attraverso le quali host esterni (311, 341) possono accedere a detti host interni (23), detta piattaforma primaria virtuale (12, 1P) essendo configurata per impostare interazioni tra detti host esterni (311, 341) e detti host interni (23), in cui detto dominio di host interno (23) comprende un insieme ulteriore di host virtuali (24), ciascuno configurato per operare come un proxy tra un’interfaccia di ingresso/uscita (25) e un’applicazione (14), ciascuna interfaccia di ingresso/uscita (25) essendo configurata per indirizzare soltanto uno tra gli host virtuali (24).
2. Dispositivo secondo la rivendicazione 1, in cui detto dispositivo sicuro (10) è configurato per effettuare un filtraggio che comprende di selezionare specifici host virtuali (24) atti a impostare un’interazione con un host interno (23) incorporato in una specifica applicazione (14) e viceversa.
3. Dispositivo secondo la rivendicazione 1 o 2, caratterizzato dal fatto che dette interazioni comprendono canali di comunicazione logici (P) aventi come estremità detti host esterni (311, 341) e detti host interni (23).
4. Dispositivo secondo una qualsiasi delle rivendicazioni da 1 a 3, caratterizzato dal fatto che detto filtrare comprende di selezionare specifici host virtuali (24) atti a impostare un canale di comunicazione logico (P) con un host interno (23) incorporato in una specifica applicazione (14) e viceversa.
5. Dispositivo secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che detto filtrare comprende di accedere a una whitelist (WL) in base a un identificatore di famiglia di firmware.
6. Dispositivo secondo la rivendicazione 5, caratterizzato dal fatto che detta whitelist (WL) è caricata con il caricamento del firmware.
7. Dispositivo secondo la rivendicazione 5, caratterizzato dal fatto che detto identificatore di famiglia di firmware è ottenuto da un descrittore dell’applicazione (14).
8. Dispositivo secondo la rivendicazione 6 o 7, caratterizzato dal fatto che detto identificatore di famiglia di firmware è un descrittore di UUID.
9. Dispositivo secondo la rivendicazione 1 caratterizzato dal fatto che è un dispositivo di Piattaforma Sicura Intelligente incorporata e detta piattaforma primaria virtuale è una Piattaforma Primaria Virtuale GlobalPlatform.
10. Dispositivo secondo la rivendicazione 1 caratterizzato dal fatto che è configurato per verificare l’autorizzazione di una richiesta di identificazione di una famiglia di firmware specifica per un firmware specifico durante il caricamento del firmware, in particolare implementato dal TRE o un suo loader.
11. Procedimento per gestire l’accesso tra host interni e un host esterno in un dispositivo sicuro (10), impostando (530) interazioni tra detti host esterni (311, 341) e detti host interni (23), in particolare canali di comunicazione logici (P) aventi come estremità host esterni (311, 341) e host interni (23), secondo una qualsiasi delle rivendicazioni da 1 a 9, comprendente aggiungere a detto dominio di host interno (23) un insieme ulteriore di host virtuali (24), ciascuno configurato per operare come un proxy tra un’interfaccia di ingresso/uscita (25) e un’applicazione (14), indirizzando con ciascuna interfaccia di ingresso/uscita (25) soltanto uno tra gli host virtuali (24).
12. Procedimento secondo la rivendicazione 10, comprendente di filtrare, selezionando specifici host virtuali (25) atti a interagire con un host interno (23) incoroporato in una specifica applicazione (14) e viceversa.
13. Procedimento secondo la rivendicazione 12, in cui detto filtraggio comprende di registrare una whitelist degli host virtuali per una data applicazione durante il caricamento del firmware di detta applicazione. Dispositivo secondo la rivendicazione 1, avente un procedimento per verificare l’autorizzazione di una richiesta di identificazione di una famiglia di firmware specifica per un firmware specifico durante il loader del firmware implementato dal TRE o un suo loader
14. Procedimento secondo la rivendicazione 12, in cui detto impostare (530) canali di comunicazione logici (P) aventi come estremità detti host esterni (311, 341) e detti host interni (23) imposta detti canali di comunicazione logici (P) come comprendenti detti host virtuali (25) selezionando le estremità in base alla configurazione di proxy degli host virtuali (25) e ai criteri di selezione specificati in detta fase di filtraggio (520), in particolare da detta fase (125) di registrazione di una whitelist degli host virtuali per una data applicazione durante il caricamento del firmware di detta applicazione.
15. Prodotto informatico che può essere caricato nella memoria di almeno un processore e comprende porzioni di codice software per implementare il procedimento secondo una qualsiasi delle Rivendicazioni da 11 a 14.