IT202100031439A1 - Sistema elettronico di protezione fisica e delle chiavi crittografiche di un sistema informatico - Google Patents

Description

Sistema elettronico di protezione fisica e delle chiavi crittografiche di un sistema informatico

La presente invenzione riguarda un sistema elettronico di protezione fisica delle chiavi crittografiche di un sistema informatico, le quali vengono cancellate a seguito di un tentativo di effrazione fisica.

Stato della tecnica

Nel contesto operativo, un sistema d?arma pu? essere dispiegato in zone ad alto rischio, per cui la Forza Armata deve fronteggiare il problema di garantirne il corretto funzionamento ed il raggiungimento degli obiettivi della missione militare. Deve essere evitato l?accesso non autorizzato alle componenti del sistema e nel caso di perdita di controllo del sistema nel campo di battaglia deve essere garantita la tempestiva cancellazione in sicurezza delle informazioni critiche (di tipo classificato e/o mission critical) contenute al suo interno, prima che le forze nemiche ne prendano possesso.

A tal fine, ? desiderabile avere una gestione remota e centralizzata del sistema riguardo alla sua sicurezza, garantendo tuttavia anche l?indipendenza del sistema. ? ancora desiderabile la cancellazione istantanea delle chiavi crittografiche e del contenuto dei supporti di memoria persistente (crittografato con tali chiavi) sia in modalit? software sia in modalit? hardware, se dotati, in questo ultimo caso, di un pin esterno per attivare la funzionalit? di hardware erase.

? sentita quindi l?esigenza di una soluzione innovativa per risolvere la problematica della gestione dell?anti-tampering in un sistema complesso. Questa gestione ? notoriamente difficoltosa poich? ? necessario garantire la sicurezza fisica degli apparati ma, al tempo stesso, permettere agli operatori di agire sugli apparati e/o di eseguire eventuali procedure di manutenzione senza rischiare di attivare involontariamente il sistema anti-tampering con l?eventuale cancellazione dei dati contenuti nell?apparato. Al contrario, ? desiderabile che l?operatore, se autorizzato, possa disabilitare temporaneamente il monitoraggio centralizzato per permettere l?esecuzione di operazioni di manutenzione sull?apparato in completa sicurezza.

Scopo e oggetto dell?invenzione

Scopo della presente invenzione ? quello di fornire un dispositivo anti-tampering che risolva i problemi e superi gli inconvenienti della tecnica nota.

? oggetto della presente invenzione un dispositivo secondo le allegate rivendicazioni.

Descrizione dettagliata di esempi di realizzazione dell?invenzione

Lista delle figure

L?invenzione verr? ora descritta a titolo illustrativo ma non limitativo, con particolare riferimento ai disegni delle figure allegate, in cui:

- la figura 1 mostra un?architettura client/server per il sistema secondo l?invenzione, secondo una sua forma realizzativa;

- la figura 2 mostra un descrive in dettaglio alcuni elementi di cui ogni sottosistema del sistema secondo l?invenzione pu? essere costituito, secondo un aspetto dell?invenzione:

- La figura 3 descrive in dettaglio i flussi logici dei componenti Server e di un generico Client e le relazioni tra i due, secondo un aspetto dell?invenzione; e

- la figura 4 mostra un esempio del motore di gestione delle policy del sistema, secondo una forma realizzativa dell?invenzione.

Si specifica qui che elementi di forme di realizzazione differenti possono essere combinati insieme per fornire ulteriori forme di realizzazione senza limiti rispettando il concetto tecnico dell?invenzione, come il tecnico medio del ramo intende senza problemi da quanto descritto.

La presente descrizione inoltre fa riferimento alla tecnica nota per la sua implementazione, riguardo alle caratteristiche di dettaglio non descritte, come ad esempio elementi di minore importanza usualmente utilizzati nella tecnica nota in soluzioni dello stesso tipo.

Quando si introduce un elemento si intende sempre che pu? essere ?almeno uno? o ?uno o pi??.

Quando si elenca una lista di elementi o di caratteristiche in questa descrizione si intende che il trovato secondo l?invenzione ?comprende? oppure alternativamente ?? composto di? tali elementi.

Quando si elencano delle caratteristiche nell?ambito di una stessa frase o lista puntata, una o pi? delle singole caratteristiche possono essere incluse nell?invenzione senza connessione con le altre caratteristiche della lista.

Forme di realizzazione

L?invenzione fornisce una risposta efficace ai problemi sopra esposti, a mezzo di una soluzione tecnica di avanguardia, consentendo una gestione completa e sicura di un kit di sensori anti-tampering di cui un sistema/sotto-sistema d?arma pu? essere equipaggiato. A titolo esemplificativo, ma non esaustivo, MBDA ATM pu? gestire sensori di temperatura, tensione, pressione, ottici, volumetrici (infrarosso e/o microonde) e di manomissione meccanica, quali switch meccanici e metal mesh di protezione. Un mix di sensori meccanici ed ottici pu? gi? costituire un?ottima combinazione contro l?accesso non autorizzato a rack o cestelli elettromeccanici che ospitano al loro interno Single Board Computers.

Il sistema secondo l?invenzione pu? essere basato su un?architettura client/server per permettere una gestione remota e centralizzata (attraverso un server primario o centrale) dei sensori e una gestione periferica dei cosiddetti client (o ?dispositivi elettronici client?), dislocati all?interno di sottosistemi (subsystems), garantendo la protezione e sicurezza del Sistema anche nel caso in cui il server non risulti disponibile o non sia raggiungibile a livello di connettivit? di rete locale.

Il sistema secondo l?invenzione permette, inoltre, la cancellazione istantanea delle chiavi crittografiche e del contenuto dei supporti di memoria persistente (crittografati con tali chiavi) sia in modalit? software sia in modalit? hardware, se dotati, in questo ultimo caso, di un pin esterno per attivare la funzionalit? di hardware erase.

Il principale scopo del server ? quello di configurare le security policy dei client, mentre il monitoraggio dei sensori remoti, e l?eventuale reazione tecnica alla violazione delle policy definite, ovvero l?esecuzione di un?azione, sono a carico dei client.

Per garantire la confidenzialit?, l?autenticit? e l?affidabilit? dei messaggi scambiati tra il server ed i suoi client, ogni dispositivo secondo l?invenzione ? dotato di un Hardware Security Module (HSM) per la gestione (es. generazione, archiviazione) delle chiavi crittografiche da utilizzare per la comunicazione client/server e per l?esecuzione di primitive crittografiche in completa sicurezza, senza richiedere che le chiavi siano mai esportata dall?HSM stesso. In sostanza, il dispositivo ATM secondo l?invenzione ? equipaggiato con dei Secure Element che permettono il salvataggio di informazioni crittografiche e l?esecuzione di funzioni crittografiche ad alta velocit? garantendo integrit? e autenticazione delle informazioni. I Secure Element hanno il livello di garanzia informatica tipica delle smart card utilizzate anche in settori finanziari.

Il sistema qui descritto ? una soluzione innovativa per risolvere la problematica della gestione dei sensori anti-tampering in un Sistema complesso. Questa gestione ? notoriamente difficoltosa poich? ? necessario garantire la sicurezza fisica degli apparati ma, al tempo stesso, permettere agli operatori di agire sugli apparati e/o di eseguire eventuali procedure di manutenzione senza rischiare di attivare involontariamente il sistema anti-tampering con l?eventuale cancellazione dei dati contenuti nell?apparato. Al contrario, grazie alla soluzione proposta, l?operatore, se autorizzato attraverso un sistema di certificati (es. Smart Card, Hardware Token di tipo USB o wireless), pu? disabilitare temporaneamente il monitoraggio su qualsiasi client del sistema per permettere l?esecuzione di operazioni di manutenzione sull?apparato in completa sicurezza.

L?architettura client/server 100 ? descritta nella figura 1; essa comprende i seguenti elementi:

? N sottosistemi client 110, 120 ? ovvero N sottosistemi da proteggere (ad esempio dei rack); - un server centrale 140 ? per la gestione centralizzata dei client;

- sensori anti-tampering 112 e 122 ? per il rilevamento dei tentativi di effrazione fisica che risultano attestati sui Sub-Systems.

Opzionalmente, per garantire l?interconnessione tra i vari dispositivi ? indicato nella figura 1 uno switch o gateway 130 (o altri adeguati mezzi del client e/o del server o terzi) ? per permettere la comunicazione tra i client ed il server.

Ogni sotto-sistema ? dotato di un modulo (ATM) Client 111, 121, mentre il server centrale ? equipaggiato con rispettivi moduli (ATM) server 141. I moduli possono essere gli stessi su client e server, solo inizializzati in modo diverso.

La figura 2 descrive in dettaglio gli elementi essenziali di cui ogni sotto-sistema 210, 220 ? costituito, ovvero:

- Modulo Client 211;

- Dispositivo di memorizzazione di massa 212 con capacit? Hardware Pin Erase;

- Kit (insieme di uno o pi?) di sensori anti-tampering 213 configurati per il rilevamento dei tentativi di effrazione fisica degli uno o pi? dispositivi elettronici client;

- Uno o pi? alimentatori di potenza 214 (o ?sistema di alimentazione di potenza?) del dispositivo client (e.g. rack).

Il modulo client pu? essere dotato anche di un ingresso per una batteria tampone per garantire il funzionamento in assenza di corrente.

In fase di installazione e configurazione deve essere effettuato il corretto accoppiamento o ?pairing? tra i moduli server e client, il quale sar? reso possibile attraverso l?utilizzo appropriato della crittografia asimmetrica (ad esempio algoritmi RSA, ECDSA) attraverso una rete di comunicazione dati in s? nota o futura. Ciascun modulo client potr? generare al suo interno una coppia di chiavi ed esporter? in modo sicuro la chiave pubblica al modulo server che lo potr? inserire in una lista dei client autorizzati (whitelist) sulla base delle rispettive chiavi pubbliche ricevute. Ciascun client potr? contenere internamente la chiave pubblica dell?unico server con cui ? abilitato a comunicare. Le comunicazioni tra client e server potranno essere rese sicure, avendo cura di garantire principalmente integrit? ed autenticit?, utilizzando una firma digitale (ad es. applicazione di hashing ai messaggi utilizzando la chiave privata del client, i quali hash possono essere cifrati con algoritmi quali RSA/ECDSA).

In tal modo la soluzione risulter? robusta rispetto ad attacchi di tipo ?man in the middle?, ?replay attacks?, ?spoofing or impersonating?, etc. La tipologia di messaggi in transito tra i moduli server e client non necessita di ulteriori protezioni per garantire la confidenzialit? del dato in transito, in quanto i messaggi scambiati non necessitano di essere protetti da esfiltrazione.

Durante lo stato operativo, il modulo client 211 monitora costantemente i sensori 213 a cui ? collegato attraverso le rispettive interfacce 2111, 2112. Nel caso in cui uno dei sensori 213 rilevi un tentativo di manomissione, ovvero intrusione fisica, l?unit? pu? cancellare il contenuto dei dischi (o dispositivi di memorizzazione di massa) 212 attraverso l?interfaccia 2114; inoltre, pu? disabilitare, o resettare, l?alimentazione dell?intero sottosistema controllando direttamente gli alimentatori di potenza del rack 214 attraverso le interfacce 2115 e 2116. La disabilitazione dell?alimentazione del sottosistema consente di evitare che lo stesso sia utilizzato impropriamente o nel caso sia implementata la cifratura delle proprie memorie di massa (data confidentiality at rest), renderebbe inaccessibile l?accesso alle informazioni sensibili, ivi memorizzate. Questa operazione sull?alimentazione di potenza ? possibile sia in presenza sia in assenza di comunicazione con il server centrale.

L?operativit? del sistema ? garantita a prescindere dalla disponibilit? del modulo Server 240 e/o del gateway centrale 230 poich? il monitoraggio e l?attivazione delle interfacce pu? avvenire direttamente sull?unit? Client 211.

L?interfaccia ethernet 2113 pu? essere utilizzata per ricevere dal Server centrale 240 le security policy con cui configurare ogni unit? client 211, le quali saranno poi rispettate a prescindere dalla disponibilit? del Server 240. L?interfaccia 2113 pu? essere utilizzata dal Client per inviare i propri log (utilizzando protocolli standard quali syslog, syslog-ng, rsyslog, etc.) e/o eventuali allarmi di manomissione/effrazione fisica all?unit? centrale 240. Infine, l?interfaccia 2113 pu? essere utilizzata dal modulo Server 240 per abilitare l?interfaccia 2114 sull?unit? client 211 e cancellare istantaneamente il contenuto di tutti i dischi 212 presenti nel sottosistema 210, attraverso uno specifico comando/messaggio/istruzione di cancellazione. L?affidabilit? di questo messaggio, onde evitare cancellazioni involontarie dei sotto-sistemi, ? garantita da una sequenza di messaggi ad hoc che assicura una bassissima probabilit? che questo messaggio venga involontariamente generato da errori casuali che possono scaturire durante il normale funzionamento del sistema 200.

La figura 3 descrive in dettaglio i flussi logici dei componenti Server e di un generico Client e le relazioni tra i due.

In particolare, analizzando per primo il componente server 340, possiamo seguire tutto il processo e la fase iniziale di boot 341 dove vengono eseguite delle attivit? preliminari al funzionamento del sistema e la successiva fase di Inizializzazione Server 342, all?interno della quale vengono ricercate e caricate le policy locali che serviranno a definire i successivi passaggi.

In particolare, la policy pu? essere vista come una regola che pu? contenere un insieme di security policy che includono istruzioni di reazione ai dati rilevati da detti uno o pi? sensori anti-tampering. Ad esempio, in maggiore dettaglio, essa pu? contenere i seguenti elementi:

- ?origine trigger?,

- ?range? ovvero delle condizioni di attivazione, - ?reazione/effetto? a fronte di ?origine trigger? nel rispetto delle condizioni di attivazione del ?range?.

L??origine trigger?, (che si verifica all?interno del range condizioni) ? l?elemento che innesca l?evento ?Detezione Effrazione? e a valle del quale verr? eseguito l?effetto configurato, e pu? essere un identificativo della tipologia di allarme definito sulla base dei dati rilevati da detti uno o pi? sensori anti-tampering. Il range comprende condizioni di reazione per la tipologia di allarme.

Una volta caricate tutte le policy, il server passa in modalit? ?Protezione Effrazione Attivata? 343 e rimane in tale modalit? fino alla detezione di un evento di tampering (o fino allo spegnimento del sistema).

A seguito della detezione dell?evento di tampering, il sistema, oltre che ritornare di nuovo nella modalit? ?Protezione Effrazione Attivata? 343, esegue il motore per la gestione dell?evento identificato con ?Individuazione del Task di Reazione? 344.

All?interno del compito ?Individuazione del Task di Reazione? 344, il sistema seleziona in automatico la controreazione che deve essere eseguita e definita all?interno delle policy sotto forma di effetto.

Le possibilit? di controreazione possono essere molteplici, e condizionate alla ?origine trigger? e al range delle condizioni di attivazione. Riportiamo, a titolo di esempio, alcune policy indicative per chiarire questo aspetto:

Policy 1:

Origine trigger: sensore luminosit?

Range: < 10 lumen

Reazione/effetto: invio messaggio warning

Policy 2:

Origine trigger: sensore luminosit?

Range condizioni: > 11 lumen

Reazione/effetto: invio comando purge

Policy 3:

Origine trigger: sensore movimento AND sensore luminosit?

Range condizioni: >X AND <Y

Reazione/effetto: invio messaggio

Come ? possibile vedere, tutti i campi delle policy permettono una formulazione complessa delle regole.

Per una descrizione dettagliata del motore (o modulo) di gestione delle policy si faccia riferimento alla Figura 3.

Come ultimo step, il sistema esegue l??effetto? definito nelle policy (?Esecuzione Reazione? 345). L?elenco delle possibili controreazioni (effetti) pu? variare dal semplice tracciamento dell?evento nei log di sistema, al pi? invasivo invio del comando di cancellazione dei dischi (purge) e spegnimento del sistema, passando per una serie di livelli intermedi (ad esempio allarme visivo, ad esempio con accensione spia led luminoso, o allarme sonoro, allarmi comandabili in base alle suddette istruzioni di reazione). La possibile gradazione del tipo di effetto ? anch?essa parte del livello di configurabilit? delle policy.

Il componente Client #N 320 ha anch?esso una fase iniziale di boot 321, successivamente alla quale viene eseguito il primo controllo 322: se ? connesso il componente server, oppure, se non sono state acquisite le policy a livello locale, il sistema cerca la connessione al server al fine di ricevere le policy.

Una volta acquisite le policy dal server 323 (ma anche quando il client ha gi? delle policy acquisite in precedenza e non c?? una connessione attiva col server), viene eseguita una sequenza di task del tutto equivalente a quanto ? stato precedentemente descritto parlando del server 340. In dettaglio, verr? eseguita una fase di inizializzazione 324 e poi il sistema eseguir? il compito ?Protezione Effrazione Attivata? 325.

A seguito della rilevazione dell?evento di tampering, il sistema client, oltre che ritornare di nuovo nella modalit? ?Protezione Effrazione Attivata? (325), esegue il motore per la gestione dell?evento identificato con ?Individuazione del Task di Reazione? 326, dove verr? selezionata la reazione che verr? eseguita nel compito ?Esecuzione Reazione? 327.

In questa fase, la differenza rispetto alla gestione lato server ? l?aggiunta di una nuova segnalazione 328 proprio verso il server che permette poi un ulteriore livello di gestione centralizzato dell?effetto.

La figura 4, permette di descrivere in dettaglio il principio di funzionamento del sistema dal momento della rilevazione dell?evento all?applicazione dell?effetto.

All?ingresso dell?algoritmo, ogni detezione porta con s? due attributi necessari per la corretta selezione della controreazione: il sensore che ha rilevato l?anomalia ed il valore di range associato.

Come si pu? notare, tutte le rilevazioni vengono elaborate centralmente da un elemento 410a che, in funzione del tipo di sensore che le ha generate, le smista 410b ad un secondo livello di filtro 420. In questo secondo livello 420, questi eventi vengono nuovamente suddivisi, stavolta in base al valore del range.

Al termine della fase di classificazione, il quarto livello del processo ? dedicato alla individuazione della policy 430. Se la policy ? costruita per un solo rilevamento, allora il sistema esegue la reazione associata 450. Se invece la policy si costruisce con pi? rilevamenti (in AND e/o in OR tra di loro) sempre in questo livello viene fatta la riconciliazione (temporale) 440, attendendo i rilevamenti di tutti gli altri eventi prima di passare al livello successivo.

Il tempo entro il quale il sistema attende la riconciliazione ? configurabile. Al superamento del timeout, il rilevamento viene fatto uscire dal sistema e scartato in 460 perch? non ha rispettato nessuna policy.

Due o pi? tra le parti (elementi, dispositivi, sistemi) sopra descritte possono essere associate liberamente e considerate come kit di parti secondo l?invenzione.

Vantaggi dell?invenzione

Al contrario degli attuali moduli anti-tampering esistenti sul mercato, l?invenzione sfrutta un?architettura client/server per garantire la massima sicurezza e flessibilit?. Il modulo ATM dell?invenzione deve essere configurato preliminarmente in modalit? hardware, una sola volta in modo irreversibile, per funzionare in ?Client mode? o ?Server mode?. La modalit? settata non potr? essere successivamente modificata per ragioni di sicurezza.

Inoltre, il form factor XMC ? Switched Mezzanine Card, standard noto VITA 42.3? un aspetto vantaggioso poich? pu? essere utilizzato senza problemi nell?ambito militare o in ambienti che richiedano il soddisfacimento di requisiti ambientali stringenti.

Un caso d?uso tipico del dispositivo secondo l?invenzione ? un sistema d?arma e specificatamente all?interno di un Tactical Operation Center (ToC) o su un lanciatore missilistico, a bordo dei quali sono presenti diversi sottosistemi rack contenenti informazioni sensibili, spesso classificate. Dotando ogni rack degli ATM secondo l?invenzione, ? possibile proteggere le informazioni contenute in questi sistemi, evitando che tali informazioni finiscano in mani nemiche, laddove, si debba abbandonare il sistema e, in ogni caso, evitando che un manutentore non autorizzato tenti di accedere a parti del sistema.

Il dispositivo ATM potrebbe essere applicato anche al mondo civile in un contesto di infrastrutture critiche, ad esempio in ambito data center, andando a proteggere pi? sottosistemi rack di un CED (Centro Elaborazione Dati).

In quel che precede sono state descritte le preferite forme di realizzazione e sono state suggerite delle varianti della presente invenzione, ma ? da intendersi che gli esperti del ramo potranno apportare modificazioni e cambiamenti senza con ci? uscire dal relativo ambito di protezione, come definito dalle rivendicazioni allegate.

Claims (10)

RIVENDICAZIONI

1. Sistema (100) elettronico di protezione fisica delle chiavi crittografiche di un sistema informatico, comprendente:

- Uno o pi? dispositivi elettronici client (110,120,210,220);

- Un server centrale (140, 240, 340) per la gestione remota e centralizzata degli uno o pi? dispositivi elettronici client;

in cui ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220) include:

- un modulo client (211);

- almeno un dispositivo di memorizzazione di massa (212) configurato per abilitare un Hardware Pin Erase;

- uno o pi? sensori anti-tampering (112, 122, 213) configurati per il rilevamento dei tentativi di effrazione fisica di detti uno o pi? dispositivi elettronici client;

- un sistema (214) di alimentazione di potenza;

- mezzi di comunicazione (130) con il server centrale;

ed in cui ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220) ? configurato per:

- effettuare un accoppiamento o ?pairing? con detto server (140, 240, 340) utilizzando un algoritmo di crittografia asimmetrica, attraverso una rete di comunicazione dati;

- monitorare costantemente detti uno o pi? sensori anti-tampering (112, 122, 213) a cui ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220) ? collegato attraverso rispettive interfacce (2111, 2112);

- cancellare il contenuto di detto almeno un dispositivo di memorizzazione di massa (212) nel caso in cui uno di detti uno o pi? sensori antitampering (112, 122, 213) rilevi un tentativo di manomissione, ovvero di intrusione fisica, in presenza o meno di connessione con detto server centrale; e

- disabilitare, o resettare, detto sistema di alimentazione (214) attraverso rispettive interfacce (2115, 2116) di sistema di alimentazione, a prescindere dalla presenza o meno di connessione con detto server centrale.

2. Sistema secondo la rivendicazione 1, in cui ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220) ? configurato per inviare al server centrale (140, 240, 340) propri log e/o allarmi di effrazione fisica.

3. Sistema secondo la rivendicazione 1 o 2, in cui ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220) ? configurato per ricevere un comando da detto server centrale (140, 240, 340) una istruzione di cancellazione del contenuto di detto almeno un dispositivo di memorizzazione di massa (212).

4. Sistema secondo una o pi? delle rivendicazioni da 1 a 3, in cui ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220) ? configurato per ricevere un insieme di security policy che includono istruzioni di reazione ai dati rilevati da detti uno o pi? sensori anti-tampering (112, 122, 213).

5. Sistema secondo la rivendicazione 4, in cui l?insieme di security policy comprende regole che includono i seguenti elementi:

- identificativo della tipologia di allarme definito sulla base dei dati rilevati da detti uno o pi? sensori anti-tampering;

- condizioni di reazione per la tipologia di allarme;

e

- istruzioni di reazione a fronte di detto identificativo nel rispetto delle condizioni di reazione.

6. Sistema secondo la rivendicazione 5, in cui detti uno o pi? dispositivi elettronici client (110,120,210,220) comprendono mezzi di allarme sonoro e/o visivo comandabili in base a dette istruzioni di reazione.

7. Sistema secondo la rivendicazione 5 o 6, in cui, nel caso in cui dette istruzioni di reazione sono funzione di pi? rilevamenti di detti uno o pi? sensori anti-tampering, detti uno o pi? dispositivi elettronici client (110,120,210,220) essendo configurati per riconciliare temporalmente (440) i rilevamenti prima di eseguire le istruzioni di reazione.

8. Sistema secondo la rivendicazione 7, in cui detti uno o pi? dispositivi elettronici client (110,120,210,220) sono configurati per riconciliare temporalmente (440) i rilevamenti entro un tempo predefinito dal primo rilevamento in ordine temporale.

9. Sistema secondo una o pi? delle rivendicazioni da 1 a 8, in cui ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220) ? configurato per effettuare detto accoppiamento o ?pairing? con detto server (140, 240, 340) effettuando le seguenti fasi:

- generare e memorizzare al suo interno una coppia di chiavi pubblica e privata;

- esportare la chiave pubblica al server centrale utilizzando una firma digitale;

in cui il server centrale ? configurato per inserire ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220) in una lista di dispositivi elettronici client autorizzati sulla base delle rispettive chiavi pubbliche ricevute.

10. Sistema secondo la rivendicazione 9, in cui detta firma digitale comprende una funzione di hashing sulla base di una chiave privata per ciascuno di detti uno o pi? dispositivi elettronici client (110,120,210,220).