IT201800011129A1 - Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain - Google Patents

Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain Download PDF

Info

Publication number
IT201800011129A1
IT201800011129A1 IT102018000011129A IT201800011129A IT201800011129A1 IT 201800011129 A1 IT201800011129 A1 IT 201800011129A1 IT 102018000011129 A IT102018000011129 A IT 102018000011129A IT 201800011129 A IT201800011129 A IT 201800011129A IT 201800011129 A1 IT201800011129 A1 IT 201800011129A1
Authority
IT
Italy
Prior art keywords
block chain
transaction
hardware
hardware interface
private key
Prior art date
Application number
IT102018000011129A
Other languages
English (en)
Inventor
Giacomo Baldi
Gualtiero Fantoni
Daniele Mazzei
Gabriele Montelisciani
Original Assignee
Toi Srl
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toi Srl filed Critical Toi Srl
Priority to IT102018000011129A priority Critical patent/IT201800011129A1/it
Priority to US17/298,857 priority patent/US11960613B2/en
Priority to EP19838952.0A priority patent/EP3895044A1/en
Priority to PCT/IB2019/060750 priority patent/WO2020121265A1/en
Publication of IT201800011129A1 publication Critical patent/IT201800011129A1/it

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/34User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/606Protecting data by securing the transmission between two devices or processes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Electrotherapy Devices (AREA)
  • Computer And Data Communications (AREA)

Description

TITOLO:
“Sistema, dispositivo e metodo per trasferire in modo sicuro informazioni da un hardware a una catena a blocchi.”
CONTESTO DELL’INVENZIONE
La nuova frontiera degli attacchi informatici alla sicurezza sta rapidamente passando dai singoli computer alle aziende, trovando sempre modi nuovi e più sofisticati per estorcere denaro o compromettere gli affari. Questa tendenza è dimostrata dai recenti attacchi a grandi aziende a livello mondiale che operano in diversi settori come trasporti, logistica, settore bancario e anche strutture militari. Le aziende molto spesso possiedono o fanno parte di catene di fornitura in cui un’impresa integrata gestisce l’intera catena logistica condividendo le informazioni con i propri partner o con gli altri componenti della catena di fornitura. Alcune di esse trattano affari che coincidono parzialmente e, sebbene esse collaborino in una catena di fornitura, possono essere concorrenti in altri mercati o attività. Pertanto, un possibile attacco informatico a una delle aziende della catena di fornitura può incidere sulla catena di fornitura, ma può anche alterare la competizione al di fuori della catena di fornitura.
Le merci nei magazzini vengono generalmente monitorate mediante sistemi di controllo basati su sensori. Senza una protezione anti-manomissione efficace, un aggressore informatico può, ad esempio, manomettere detti sistemi al fine di ridurre la scorta di un componente nel magazzino di un singolo fornitore imitando in questo modo una prossima/incombente carenza della scorta. Pertanto, viene generato un ordine immediato (talvolta vengono attivati ordini automatici in caso di carenze della scorta) per rifornire il magazzino, in base a un’informazione scorretta. L’attacco informatico per fingere una carenza di scorta imminente può essere lanciato quando i costi della materia prima sono più elevati, provocando in questo modo costi aggiuntivi e alterando in ultima analisi la concorrenza leale all’interno e all’esterno della catena di fornitura.
Dopo che l’ordine è stato inoltrato, l’aggressore informatico può anche ripristinare il valore corretto della scorta, cancellando praticamente in questo modo le tracce della propria manomissione o quanto meno rendendo molto difficile effettuare il rilevamento della manomissione.
Un altro scenario tipico di attacco informatico alla sicurezza è quando l ’aggressore informatico opera in senso opposto, aumentando le quantità di alcune o di tutte le materie prime nel magazzino. Confidando nel sistema di gestione automatico del magazzino, nessuno si accorge degli articoli mancanti e la produzione si arresta a causa della mancanza della scorta di una o più parti. Di conseguenza, il fornitore responsabile degli articoli mancanti dalla scorta dovrà pagare delle penali. In alcuni casi, il fornitore può essere rimosso dalla catena di fornitura.
Gli attacchi informatici alla sicurezza perpetrati contro imprese che fanno parte di una catena di fornitura di aziende che condividono informazioni sensibili possono quindi causare problemi di competenza sleale tra le aziende della catena di fornitura. Un fornitore A di un determinato componente all’interno di una catena di fornitura SC1 può essere un concorrente del fornitore B in un’altra catena di fornitura SC2. Avendo accesso a informazioni sensibili riguardanti il fornitore B nella catena di fornitura SC1 (ad esempio riguardanti guasti alle macchine, riprogrammazione di produzione, eccetera), il fornitore A può decidere di fare un’offerta nella catena di fornitura SC2 sapendo che il fornitore B sta affrontando problemi, guadagnando in questo modo una nuova quota di mercato in modo sleale.
Le suddette informazioni sensibili possono riguardare alcune tipologie di merci che una compagnia gestisce e tratta. Infatti, alcune merci hanno un valore che varia durante il corso della loro vita utile: i farmaci radioattivi si deteriorano secondo una propria funzione nel tempo, le merci deperibili devono essere mantenute in determinate condizioni di temperatura, le merci fragili devono essere tenute al di sotto di una determinata sollecitazione di accelerazione massima (impatti). Pertanto, il valore di queste merci cambia a seconda del tempo del trasporto, della situazione tempo-temperatura, dell’accelerazione alla quale vengono sottoposte, e di altri parametri chiave. Possono quindi essere firmati contratti di fornitura che prevedono valori e accordi diversi secondo una particolare funzione a seconda di uno o più parametri chiave monitorati. È evidente che il monitoraggio e la seguente trasmissione di tali parametri (normalmente eseguiti mediante sistemi di controllo associati a un numero di sensori) è un compito sensibile che può essere soggetto ad attacchi informatici potenzialmente dannosi.
In altri scenari di attacchi informatici alla sicurezza, i parametri di controllo di alcuni apparecchi, gestiti da sistemi di controllo associati a sensori, possono essere leggermente alterati e modificati, giorno per giorno, mantenendo al contempo il valore riportato sull’interfaccia di controllo dell’apparecchio stabile a livello nominale. Questo porterà l’apparecchio a funzionare fuori dall’intervallo di lavoro corretto provocando una sollecitazione anomala e guasti e danni precoci.
Sarebbe dunque auspicabile progettare e fornire un metodo e un dispositivo per la comunicazione sicura di dati, atti a interfacciare gruppi di sensori e molteplici macchine industriali in base a microcontrollori o a microprocessori di basso livello in modo sicuro, superando in questo modo gli inconvenienti summenzionati.
BREVE DESCRIZIONE DELL’INVENZIONE
I microcontrollori sono dispositivi elettronici integrati su un singolo chip. Anche se il loro principio di funzionamento è comune ai microprocessori, i microcontrollori si differenziano per il fatto che supportano su di essi gli elementi di memoria e i dispositivi di interfaccia necessari per il controllo digitale di specifiche applicazioni, principalmente in sistemi integrati che includono sensori e attuatori per i fini più svariati. Sfortunatamente, i microcontrollori hanno uno spazio di memoria e risorse computazionali limitati che, di conseguenza, rendono complesso l’uso di primitive crittografiche (ad esempio, http basati su una notevole aritmetica integrale) per comunicazioni sicure tra di essi o con altre macchine, gateway, eccetera. Tale mancanza di risorse ha limitato anche l’adozione di altre tecnologie basate sulla crittografia come, ad esempio, una catena a blocchi o altri registri distribuiti. Gli stessi inconvenienti valgono per i microprocessori di basso livello.
La presente divulgazione è rivolta a metodi e sistemi per acquisire dati da una fonte (ad esempio, un gateway di rete di dati o una macchina industriale dotata di PLC, Controllori Logici Programmabili, o altri tipi di controllori, microcontrollori, microprocessori di basso livello, o di un gruppo di sensori), generare una transazione dai dati, codificare la transazione per mezzo di chip di sicurezza alimentati da hardware e infine trasferire in modo sicuro la transazione a una catena a blocchi usando un dispositivo basato su un microcontrollore o un dispositivo generico con bassa potenza computazionale.
Un esempio di transazione può essere, ad esempio, riferito a dati riguardanti uno spostamento in magazzino dove un articolo x è stato scansionato e trasferito da una posizione a un’altra. Dunque, i dati acquisiti dal sistema della presente invenzione possono riferirsi all’evento dello spostamento in magazzino e la transazione che è generata può comprendere il codice dell’articolo x, la data e l’ora del trasferimento dell’articolo x, la posizione iniziale e finale dell’articolo x. Con il sistema secondo la presente divulgazione questa transazione viene generata, criptata e trasferita a una catena a blocchi (o altro registro distribuito) al fine di certificare in modo sicuro l’evento a cui si riferisce (nell’esempio di cui sopra, lo spostamento in magazzino dell’articolo x).
Il dispositivo secondo l’invenzione è in grado di interfacciare, senza intervento umano, una singola o molteplici macchine industriali o serie di sensori con una singola o con molteplici catene a blocchi o altre implementazioni di DLT (tecnologia a registro distribuito). Pertanto, nella presente divulgazione, occorre considerare che l’espressione “catena a blocchi” si riferisce a qualsiasi registro distribuito.
Preferibilmente, il dispositivo secondo la presente invenzione è implementato come un dongle, un hardware di dimensioni esigue atto a collegarsi a un altro dispositivo per fornirgli una funzionalità aggiuntiva.
Secondo una forma di realizzazione preferita, il dispositivo della presente invenzione è un dongle dotato di capacità di comunicazione: pertanto, il dongle genera e certifica le transazioni e le scrive inoltre in una catena a blocchi. L’hardware a cui il dongle è collegato non deve necessariamente avere capacità di comunicazione e può essere anche un lettore RFID o un beacon o un’altra parte simile di hardware (attiva o passiva) che può essere letta dal dongle al fine di acquisire le informazioni, ad esempio identità, marca temporale, o eventuali altri metadati archiviato in detto hardware, metadati che il dongle userà per scrivere un messaggio nella catena a blocchi.
Secondo un’altra forma di realizzazione preferita, il dispositivo della presente invenzione è un dongle senza capacità di comunicazione: pertanto, il dongle si limita a generare e certificare le transazioni, mentre l’hardware a cui il dongle è collegato è responsabile di scrivere le transazioni certificate nella catena a blocchi.
Secondo un’ulteriore forma di realizzazione, il dispositivo della presente invenzione è un dongle modulare atto ad essere aggiunto o integrato, ad esempio, come parte di hardware nel modulo di controllo di elettronica di un apparecchio industriale. Secondo un’altra forma di realizzazione, il dispositivo della presente invenzione è un dongle multi-immissione atto a ricevere ed elaborare dati immessi da una pluralità di fonti.
Ulteriori caratteristiche e vantaggi della presente invenzione risulteranno evidenti nella seguente descrizione di una forma di realizzazione non limitativa facendo riferimento alle figure nei disegni allegati, i quali sono schematici e mostrano blocchi funzionali che sono atti ad essere implementati con una struttura hardware secondo soluzioni di circuiteria diverse nella pratica o con una struttura software, ad esempio codificata in firmware ed eseguita da un hardware idoneo. Nel dettaglio:
BREVE DESCRIZIONE DEI DISEGNI
La Figura 1 mostra un diagramma a blocchi schematico di forme di realizzazione preferite del sistema secondo la presente divulgazione nei casi in cui a) il dispositivo dell’invenzione è dotato di mezzi di collegamento per scrivere una transazione in un registro distribuito remoto, b) il dispositivo dell’invenzione non è dotato di mezzi di collegamento per scrivere una transazione in un registro distribuito remoto;
la Figura 2 mostra un diagramma a blocchi schematico di una forma di realizzazione preferita del sistema secondo la presente divulgazione in cui è illustrato lo scambio di dati durante la fase iniziale di impostazione, “di preparazione”;
la Figura 3 mostra un diagramma a blocchi schematico di una forma di realizzazione preferita del sistema secondo la presente divulgazione in cui una chiave sicura K viene scambiata tra il dispositivo dell’invenzione e un’interfaccia hardware collegata; la Figura 4 mostra un diagramma a blocchi schematico di una forma di realizzazione preferita del sistema secondo la presente divulgazione in cui un contatore monotono di hardware è impiegato all’interno del dispositivo dell’invenzione per fornire sicurezza aggiuntiva;
la Figura 5 mostra un diagramma a blocchi schematico di una forma di realizzazione preferita del sistema secondo la presente divulgazione in cui è illustrata una prima transazione tra il dispositivo dell’invenzione e un’interfaccia hardware collegata, ed è illustrata la generazione della chiave privata di catena a blocchi;
la Figura 6 mostra un diagramma a blocchi schematico di una forma di realizzazione preferita del processo di preparazione all’interno del dispositivo dell’invenzione; la Figura 7 mostra un diagramma a blocchi schematico di una forma di realizzazione preferita di una prima transazione all’interno del dispositivo dell’invenzione;
la Figura 8 mostra una forma di realizzazione preferita del dispositivo secondo la presente divulgazione nei casi in cui a) il dispositivo dell’invenzione è dotato di mezzi di collegamento per scrivere una transazione in un registro distribuito remoto, b) il dispositivo dell’invenzione non è dotato di mezzi di collegamento per scrivere una transazione in un registro distribuito remoto;
la Figura 9 mostra un diagramma schematico a blocchi aggiuntivo di una forma di realizzazione preferita del processo di preparazione all’interno del sistema dell’invenzione con evidenziati i passaggi eseguiti dal dispositivo dell’invenzione e dall’interfaccia hardware;
la Figura 10 mostra un diagramma schematico a blocchi aggiuntivo di una forma di realizzazione preferita di una prima transazione all’interno del sistema dell’invenzione con evidenziati i passaggi eseguiti dal dispositivo dell’invenzione e dall’interfaccia hardware;
la Figura 11 mostra un diagramma a blocchi schematico di una forma di realizzazione preferita di una n<esima >transazione, quando n >1, all’interno del dispositivo dell’invenzione;
la Figura 12 mostra un diagramma a blocchi schematico di una forma di realizzazione preferita di un processo di transazione su catena a blocchi tra il dispositivo dell’invenzione e un nodo di catena a blocchi, e
la Figura 13 mostra un diagramma schematico a blocchi aggiuntivo di una di una forma di realizzazione preferita di una n<esima >transazione, quando n >1, all’interno del sistema dell’invenzione con evidenziati i passaggi eseguiti dal dispositivo dell’invenzione e dall’interfaccia hardware.
DESCRIZIONE DETTAGLIATA DELL’INVENZIONE
La presente divulgazione è rivolta a metodi, sistemi e dispositivi e sistemi per acquisire dati da una fonte (ad esempio, un gateway di rete di dati o una macchina industriale dotata di PLC - Controllori Logici Programmabili -, o altri tipi di controllori, microcontrollori, microprocessori di basso livello, o di un gruppo di sensori), estrarre informazioni dai dati, criptare le informazioni per mezzo di chip di sicurezza alimentati da hardware, generare una transazione corrispondente alle informazioni estratte dai dati e infine trasferire in modo sicuro le informazioni a una catena a blocchi - o qualsiasi altro registro distribuito generico - usando un dispositivo basato su un microcontrollore o un dispositivo generico con bassa potenza computazionale.
Il dispositivo secondo l’invenzione è in grado di interfacciare una singola o molteplici macchine industriali o serie di sensori con una singola o con molteplici catene a blocchi o altre implementazioni di DLT (tecnologia a registro distribuito), senza intervento umano. Preferibilmente, il dispositivo secondo la presente invenzione è implementato come un dongle, un hardware di dimensioni esigue atto a collegarsi a un altro dispositivo o apparecchio per fornirgli una funzionalità aggiuntiva.
Facendo riferimento alla Figura 8, una forma di realizzazione preferita del dispositivo 10 secondo l’invenzione comprende un PLC, un microcontrollore, un microprocessore di basso livello o un dispositivo generico con bassa potenza computazionale 80, un primo modulo di comunicazione 85 e un elemento di sicurezza 82 comprendente mezzi di archiviazione sicura 83 e un motore crittografico hardware 84. Un elemento di sicurezza 82 è un chip che può archiviare dati sensibili ed eseguire applicazioni sicure per svolgere compiti come, ad esempio, un pagamento. L’elemento di sicurezza 82 funge da cassaforte, proteggendo ciò che si trova all’interno dell’elemento di sicurezza 82 (sia le applicazioni sia i dati) da possibili attacchi di malware che possono verificarsi, ad esempio, nel sistema ospite. Un esempio dell’elemento di sicurezza 82 è il dispositivo disponibile in commercio ATECC608A dell’azienda Microchip<TM>.
Il primo modulo di comunicazione 85 è atto a comunicare con sistemi digitali esterni, ad esempio un’interfaccia di macchina 11 atta a collegare il dispositivo 10 con un’altra unità hardware esterna, detta interfaccia di macchina 11 essendo di seguito definita interfaccia hardware 11. L’interfaccia hardware 11 è dotata di un’unità computazionale che può essere implementata su un microcontrollore. Un secondo dispositivo 10 secondo questa divulgazione può anche essere configurato per funzionare come un’interfaccia hardware 11 e per comunicare con il primo dispositivo 10. In altre forme di realizzazione, l’interfaccia hardware 11 può comprendere un’interfaccia di macchina programmabile che può essere modificata per interagire con il dispositivo 10 dell’invenzione e il suo protocollo. In ulteriori forme di realizzazione, l’interfaccia hardware 11 può essere integrata nell’unità hardware esterna a cui il dispositivo 10 deve collegarsi.
Preferibilmente, le caratteristiche di un’interfaccia hardware 11 sono: capacità di computare primitive crittografiche di base (come, ad esempio, crittografia a curva ellittica, crittografia RSA, funzioni SHA); capacità di comunicazione (ad esempio Ethernet, Wi-Fi, Bluetooth, in serie, eccetera); capacità di archiviare dati in mezzi di memoria, preferibilmente in mezzi di memoria sicuri.
Nel seguito di questa divulgazione vengono usate le espressioni chiavi crittografiche e stringhe casuali. Queste espressioni sono definite entrambe come sequenze casuali di bit generate su un modulo hardware conforme a FIPS-140 da un generatore di bit casuali con caratteristiche approvare da standard di sicurezza come FIPS-186-3. La differenza tra le due espressioni è di natura funzionale: una chiave crittografica è una stringa casuale usata come una chiave in un algoritmo crittografico, mentre una stringa casuale non lo è. Le chiavi crittografiche sono usate per criptare messaggi per mezzo di algoritmi crittografici appropriati; in tale contesto un messaggio è definito come una sequenza di bit formattata secondo una convenzione comune al mittente e al destinatario del messaggio. I messaggi criptati, essendo sequenze di bit, possono essere trasmessi per mezzo di diverse tecnologie su mezzi diversi (campi elettromagnetici, raggi luminosi, correnti elettriche, eccetera); a prescindere dalla particolare tecnologia, si afferma che un messaggio è trasmesso su un canale; in generale, sequenze di bit trasmesse su un canale possono essere intercettate da un attore (un qualsiasi aggressore) che ha accesso a tale canale, consentendo in questo modo all’attore di leggere le informazioni trasmesse. Pertanto, se è necessario che le informazioni da trasmettere siano note solo al mittente e al destinatario desiderato, solitamente tali informazioni vengono appropriatamente modificate mediante un algoritmo crittografico (vale a dire, criptate) in modo tale che, anche se le informazioni criptate che vengono trasmesse sono lette da un aggressore, l’aggressore non possa invertire l’algoritmo crittografico in un modo fattibile a livello computazionale per ottenere le informazioni decriptate.
In merito all’interazione con una catena a blocchi o con un registro distribuito remoto generico, un tema cruciale riguardo al dispositivo 10 secondo la presente invenzione è l’archiviazione della chiave privata che controlla l’indirizzo della catena a blocchi. Questo è un tema cruciale poiché, se l’archiviazione di una chiave non è sicura, allora espone la chiave stessa a tecniche di pirateria informatica avanzate come termografia o accesso diretto all’hardware.
Attualmente, vi sono due tipi di hardware specializzati nell’archiviazione di chiavi di catena a blocchi e atti a generare transazioni: portafogli hardware e moduli di sicurezza hardware o HSM.
In merito ai portafogli hardware, la generazione di una transazione da questi dispositivi è conseguente a una decisione umana, pertanto la chiave può essere archiviata in una forma criptata che può essere decriptata richiedendo, tramite un’interfaccia umana, un pin, una password, un insieme di dati biometrici o dati più generici a partire dai quali la chiave privata originaria può essere ricostruita e usata per contrassegnare una transazione. Sebbene questo approccio sia valido per portafogli hardware progettati per soggetti umani, non è attuabile per il dispositivo secondo la presente invenzione, la cui finalità è consentire a un altro hardware collegato di partecipare in una piattaforma di catena a blocchi.
In merito agli HSM, essi possono generare e archiviare chiavi private e contrassegnare dati con dette chiavi private, adottando livelli diversi di tutela contro la manomissione. Tuttavia, il loro livello di sofisticazione ha un costo relativamente elevato ed essi sono solitamente progettati come un’archiviazione sicura per scopi generici per un numero notevole di chiavi private per applicazioni bancarie, di pagamento e di certificazione.
Anziché archiviare la chiave privata in un determinato luogo, l’approccio usato nel dispositivo di catena a blocchi secondo la presente invenzione consente di generare la chiave privata a partire da parametri contenuti in parte nel dispositivo stesso e in parte in altre unità hardware, vale a dire un’interfaccia hardware 11, che interagisce con il dispositivo 10 su un canale di comunicazione. In questo modo, qualsiasi manomissione fisica del dispositivo 10 non divulgherà la chiave privata poiché la chiave privata non è interamente archiviata né nel dispositivo né nell ’hardware collegato.
In maggior dettaglio, la chiave privata di catena a blocchi è costruita a partire da due informazioni provenienti da fonti differenti. La prima informazione è inizialmente generata e salvata in modo sicuro all’interno dell’elemento di sicurezza 82 al momento dell’inizializzazione del dispositivo. La prima informazione non è nota all’utente che esegue l’inizializzazione del dispositivo, è nota solo al dispositivo e non lascia mai il dispositivo stesso.
La seconda informazione è fornita dalla singola interfaccia hardware 11 o dalle molteplici interfacce hardware 11 a cui il dispositivo 10 è collegato attraverso il primo modulo di comunicazione 85.
Il microcontrollore del dispositivo, il suo microprocessore di basso livello o dispositivo generico con bassa potenza computazionale 80 è atto a generare un algoritmo per generare (o ricostruire) la chiave privata di catena a blocchi, contrassegnare digitalmente la transazione, erogare la transazione e successivamente eliminare la chiave privata di catena a blocchi dalla memoria. Il dispositivo di catena a blocchi secondo la divulgazione è atta a interfacciare molteplici macchine industriali o serie di sensori con molteplici catene a blocchi e altre implementazioni di DLT (tecnologia a registro distribuito), senza intervento umano.
Facendo riferimento alla Figura 1 a) e Figura 8 a) allegate, il dispositivo 10 secondo la presente divulgazione può essere dotato di un secondo modulo di comunicazione 81 per collegarsi a un server remoto dove è ospitata una catena a blocchi o un nodo di registro distribuito generico e per scrivere la transazione in una catena a blocchi. La Figura 1 a) mostra un dispositivo 10 secondo l’invenzione che, di conseguenza, è atto a generare e certificare transazioni e a scrivere le transazioni nella catena a blocchi.
In questa forma di realizzazione, il dispositivo può essere atto a leggere da un RFID o da un beacon o da una simile parte di hardware, attiva o passiva. A titolo di esempio non limitativo, il dispositivo 10 sarà associato a un lettore RFID. Ogni volta che un lettore legge un RFID (ad esempio uno spostamento in magazzino riguardante un articolo x che è stato venduto in un determinato momento y), allora i dati raccolti - ad esempio codice e identità dell’articolo, marca temporale dello spostamento, ID di operatore e altri metadati - saranno inviati dal lettore RFID al dispositivo 10 che formatterà i dati ricevuti in una transazione, contrassegnerà la transazione e la invierà alla catena a blocchi, certificando pertanto in modo sicuro che l’articolo x è stato venduto nel momento y.
La Figura 1 b) mostra un dispositivo 10 secondo la presente divulgazione senza capacità di comunicazione, mentre l’interfaccia hardware collegata 11 è dotata di mezzi di comunicazione. In questa forma di realizzazione, il dispositivo 10 si limita a contrassegnare la transazione, mentre l’hardware è responsabile di scrivere la transazione contrassegnata nella catena a blocchi.
Il protocollo di comunicazione tra l’interfaccia hardware 11 e il dispositivo 10 secondo la presente divulgazione può avvenire - attraverso il primo modulo di comunicazione 85 - su un canale con o senza fili ed è agnostico rispetto alla piattaforma su cui è eseguito e pertanto compatibile con standard esistenti riguardanti sia la crittografia sia il formato del protocollo; un’implementazione possibile e conveniente del protocollo è basata sul set di comandi Hayes, un noto set di comandi, usato per decenni nelle telecomunicazioni e nelle reti, noto anche come set di comandi AT (dove AT è l’abbreviazione di attenzione). Il set di comandi AT è stato introdotto e ampiamente usato in modem e dispositivi di modulazione/demodulazione, atti a leggere informazioni digitali, modularle su canali analogici, e restituire informazioni digitali demodulate dal formato analogico. Nel corso degli anni, il termine “modem” ha ampliato il proprio significato originario, indicando generalmente dispositivi di comunicazione usati per collegare computer ad altri computer o reti. In questo senso più ampio, il set di comandi AT si adatta perfettamente al dispositivo 10 secondo la presente divulgazione che può essere considerato come una sorta di “modem di catena a blocchi”.
Il set di comandi Hayes è caratterizzato da comandi AT di base, formati di comando e codici di risultato. È stato esteso per soluzioni personalizzate, la più nota delle quali è quella adottata per i modem del Sistema Globale per le Comunicazioni Mobili (GSM). Di conseguenza, il dispositivo 10 secondo l’invenzione può avvalersi di un set personalizzato per catena a blocchi di comandi AT per standardizzare le funzionalità della catena a blocchi esposte all’hardware collegato.
Un esempio preferito di un set di parametri, della loro generazione e gestione da parte del sistema secondo la presente divulgazione è riassunto nella seguente tabella:
Facendo riferimento alla Figura 8, preferibilmente l’elemento di sicurezza 82 (talvolta definito cripto-chip o archiviazione sicura) del dispositivo 10 secondo la presente divulgazione è un circuito integrato con le seguenti caratteristiche:
- la capacità di generare una chiave privata (dD nella tabella di cui sopra) realmente casuale (diversamente da pseudo-casuale);
- la capacità di archiviare dati in modo che sia fisicamente molto difficile accedervi (vale a dire, al sicuro da termografia o scansione a raggi X del circuito integrato) rispetto alle memorie non volatili standard;
- la capacità di eseguire un algoritmo di contrassegnazione crittografica direttamente sul circuito integrato senza esporre la chiave privata, oltre alla capacità facoltativa di avere contatori hardware non volatili che aumentano in modo monotono.
Facendo riferimento alla Figura 2 e alla Figura 9 allegate, il dispositivo 10 secondo la presente divulgazione (di seguito definito preferibilmente “dongle” secondo una delle forme di realizzazione della presente divulgazione) esegue una fase iniziale -di seguito definita fase di preparazione - di impostazione iniziale in cui il dongle 10 genera 90 un set di parametri. Questi parametri sono, per esempio, dD (Chiave Privata di Dongle), QD (Chiave Pubblica di Dongle), UIDD (Identificativo Univoco di Dongle), dH (Chiave Privata di Unità HW), QH (Chiave Pubblica di Unità HW) e UIDH (Identificativo Univoco di Unità HW). Detti parametri possono essere generati da un generatore di numeri casuali certificato per crittografia che può trovarsi all’interno del microcontrollore 80 o all’interno dell’elemento di sicurezza 82. La fase di preparazione iniziale comincia con la generazione, da parte dell ’interfaccia hardware 11 collegata al dongle 10, del parametro QH - Chiave Pubblica dell’interfaccia hardware 11 - e procede con il trasferimento del parametro QH dall’interfaccia hardware 11 all’Archiviazione Sicura di Dongle 83. È possibile anche trasferire molteplici chiavi pubbliche se sono necessarie più interfacce hardware. Successivamente, il dongle 10 procede generando 92 i parametri dD (la Chiave Privata di Dongle), QD (la Chiave Pubblica di Dongle), e UIDD (l’identificativo univoco del dongle 10), e poi trasferendo 93 il parametro QD all’interfaccia hardware 11 e salvando in modo sicuro nell’archiviazione sicura 83 i parametri QH, dD e UIDD.
Dopo la fase di preparazione, un esempio della prima transazione tra il dongle 10 e l’interfaccia hardware 11 e la generazione della chiave privata di catena a blocchi dB è raffigurato nella Figura 3 e nella Figura 10:
L’interfaccia hardware 11 e il dongle 10 cooperano per scambiarsi in modo sicuro 100 una chiave segreta K su un canale non sicuro applicando, per esempio, l’algoritmo di scambio di chiave di Diffie-Hellman (in una delle sue varianti DH, DHE, ECDH, ECDHE). L’algoritmo di Diffie-Hellman richiede 5 parametri: due coppie di chiavi pubblica-privata e le caratteristiche del dominio sul quale vengono eseguiti i calcoli (generalmente curve ellittiche or gruppi moltiplicativi di interi). Le chiavi dD, QD, dH e QH in questo passaggio vengono usate come parametri dell’algoritmo di Diffie-Hellman (dD e dH essendo le chiavi private, QD e QH le chiavi pubbliche; il dominio è determinato dalla variante di Diffie-Hellman scelta) con dD e dH che non lasciano mai la loro rispettiva archiviazione sicura, dH l’archiviazione sicura dell’interfaccia hardware 11 e dD l’archiviazione sicura 82 del dongle 10.
La chiave segreta K è usata per criptare qualsiasi comunicazione successiva tra l’interfaccia hardware 11 e il dongle 10 sul canale non sicuro. Il messaggio M (avente un qualsiasi formato, e preferibilmente avente un formato interoperabile come, ad esempio, JSON) da trasmettere dall’interfaccia hardware 11 alla catena a blocchi (il messaggio M comprendendo per esempio i dati di una lettura RFID riguardante una transazione di magazzino, o i dati riguardanti qualsiasi altro evento di interesse) viene innanzitutto criptato insieme all’Identificativo Univoco di Dongle UIDH usando la chiave K, e quindi inviato 101 al dongle 10.
Messaggi con marca temporale o con nonce crittografico possono essere usati per evitare attacchi di riproduzione. Facendo riferimento alla Figura 4, in un particolare esempio del Dongle 10, un contatore monotono di hardware N 40 può essere usato per garantire sempre che i vecchi messaggi non siano inviati nuovamente da un aggressore o da un’interfaccia hardware malfunzionante 11 sul canale. È possibile intraprendere misure di sicurezza aggiuntive generando periodicamente una chiave segreta diversa K per criptare la comunicazione sul canale non sicuro.
Facendo ancora riferimento alla Figura 4, quando viene ricevuto un messaggio, il dongle ricostruirà la chiave privata di catena a blocchi dB applicando il seguente algoritmo al messaggio ricevuto:
Per mezzo di una determinata Funzione di Derivazione di Chiave Basata su Password (vale a dire PBKDF2) applicata a una certa giustapposizione di almeno UIDH e UIDD (ma anche dD può essere usato in questo processo), viene generata l’entropia iniziale S per il calcolo deterministico di dB;
Una volta che dB è generata, essa è usata per contrassegnare le transizioni su catena a blocchi nel Dongle. La prima volta che dB viene generata, il corrispondente indirizzo pubblico di catena a blocchi QB viene derivato e archiviato nell’Archiviazione Sicura.
Successivamente, dB è immediatamente cancellata dalla memoria del Dongle. Qualsiasi successiva generazione di dB controllerà in aggiunta che il corrispondente QB sia lo stesso di quello archiviato nell’Archiviazione Sicura.
Facendo riferimento alla Figura 5, una volta che il messaggio M è convertito nel formato della catena a blocchi, può essere generata una transazione. Una volta che la transazione è contrassegnata con esito positivo con dB, essa può essere inviata direttamente alla catena a blocchi dal dongle 10 o può essere ritrasmessa all’interfaccia hardware 11 che la invierà alla catena a blocchi nel caso in cui il dongle non sia dotato di connettività.
Facendo riferimento alla Figura 6 e alla Figura 9, in maggior dettaglio il processo di preparazione all’interno del dongle 10 è eseguito come segue. L’interfaccia hardware 11 sollecita il dongle 10 inviando un comando di preparazione - ad esempio un comando di preparazione AT - su un canale non criptato e attraverso il primo modulo di comunicazione 85. Il dongle 10 ha un elemento di sicurezza vuoto 82. Il dongle 10 interpreta il comando - per esempio con un analizzatore sintattico di comandi AT - 61, il comando viene riconosciuto 62 e analizzato per estrarre 63 la chiave pubblica QH dell’interfaccia hardware 11. Successivamente, il dongle 10 (ad esempio l’elemento di sicurezza 82 del dongle 10) genera 64 una coppia chiave privata/pubblica QD/dD in modo che dD non debba mai lasciare l’elemento di sicurezza 82; allora la chiave QD viene inviata nuovamente 65 all’interfaccia hardware 11 e la chiave QH viene inviata 66 all’elemento di sicurezza 82 per essere archiviata. A questo punto, la stringa casuale UIDD viene generata 67 dal dispositivo 10 e inviata 68 all’elemento di sicurezza 82 per essere archiviata. Dunque ora, al termine del processo di preparazione, l’elemento di sicurezza 82 archivia i parametri UIDD,QD,QH e dD.
Dopo la fase di inizializzazione di preparazione, e facendo riferimento alla Figura 7 e alla Figura 10 allegate, la prima transazione viene eseguita come segue:
L’interfaccia hardware 11 inizia inviando un comando di catena a blocchi al dongle 10 in cui l’elemento di sicurezza 82 contiene UIDD,QD,QH e dD ma non ancora l’indirizzo di catena a blocchi del dongle, QB. L’interfaccia hardware 11 e il dongle 10 cooperano per scambiarsi in modo sicuro 70 una chiave segreta K su un canale non sicuro applicando, per esempio, l’algoritmo di scambio di chiave di Diffie-Hellman (in una delle sue varianti DH, DHE, ECDH, ECDHE). L’algoritmo di Diffie-Hellman richiede 5 parametri: due coppie di chiavi pubblica-privata e le caratteristiche del dominio sul quale vengono eseguiti i calcoli (generalmente curve ellittiche or gruppi moltiplicativi di interi). Le chiavi dD, QD, dH e QH in questo passaggio vengono usate come parametri dell’algoritmo di Diffie-Hellman (dD e dH essendo le chiavi private, QD e QH le chiavi pubbliche; il dominio è determinato dalla variante di Diffie-Hellman scelta) con dD e dH che non lasciano mai l’archiviazione sicura 82; la chiave segreta K è quindi usata per decriptare 71 il comando AT ricevuto in precedenza, l’Identificativo Univoco di interfaccia hardware 11, UIDH, viene estratto 72 dal comando AT insieme al messaggio M e UIDH viene archiviato nella RAM del microcontrollore del dongle 10. L’UIDD viene quindi letto dall’archiviazione sicura 82, e da UIDD e UIDH (e, facoltativamente, ulteriori informazioni aggiuntive), viene generato dB 73 e archiviato nella RAM del microcontrollore del dongle 10. L’indirizzo di catena a blocchi QB viene derivato 74 da dB e successivamente QB viene inviato 75 all’elemento di sicurezza 82 per essere archiviato al suo interno. Infine, la transazione su catena a blocchi viene generata 76 e inviata alla catena a blocchi. UIDH, dB, UIDD e QB vengono cancellate dalla RAM del microcontrollore del dongle 10.
Facendo riferimento alla Figura 11 e alla Figura 13, l’n<esima >transazione (n >1) inizia con l’interfaccia hardware 11 che invia un comando AT di catena a blocchi al dongle 10 con un elemento di sicurezza preparato che contiene l ’indirizzo di catena a blocchi del dongle QB. L’interfaccia hardware (11) e il dispositivo (10) cooperano per generare in modo sicuro e scambiarsi (70) una chiave segreta K, detta chiave segreta K essendo generata dalle chiavi dD, QD, dH e QH, ad esempio eseguendo un algoritmo di Diffie-Hellman. La chiave segreta K è usata per decriptare 111 il comando AT; successivamente UIDH viene estratto dal comando AT insieme al messaggio M e UIDH è archiviato 112 nella RAM del microcontrollore del dongle 10; UIDD viene quindi letto dall’archiviazione sicura 82, e da UIDD e UIDH (e, opzionalmente, ulteriori informazioni aggiuntive), viene generato dB 113 e archiviato nella RAM del microcontrollore del dongle 10. L’indirizzo di catena a blocchi QB viene derivato 114 da dB, e quindi QB viene controllato rispetto al QB contenuto nell’elemento di sicurezza 82: se differiscono, la transazione non viene generata e il comando fallisce 116, altrimenti viene generata una transazione su catena a blocchi 117 a partire da M e dB e infine UIDH, dB, UIDD e QB vengono cancellati dalla RAM del microcontrollore del dongle 10.
In maggior dettaglio e facendo riferimento alla Figura 12, il passaggio di generare 117 una transazione su catena a blocchi può essere eseguito come segue:
L’indirizzo QT della catena a blocchi che riceve la transazione è estratto 120 dal messaggio M; dati aggiuntivi D da includere nella transazione su catena a blocchi vengono quindi estratti 121 dal messaggio M. Una transazione su catena a blocchi T viene quindi generata 122 contrassegnando la tupla (QT,D) con dB; a questo punto T è inviata 123 a un nodo di catena a blocchi per la convalida e l’archiviazione. Il canale di comunicazione alla catena a blocchi non è necessariamente criptato. T viene quindi ricevuta 124 da un nodo di catena a blocchi ed è trasmessa a tutti i nodi adiacenti; il nodo di catena a blocchi aggrega 125 T con altre transazioni ricevute per formare un blocco; detto blocco viene modificato 126 a seconda della particolare catena a blocchi per superare l’algoritmo di consenso della catena a blocchi (per esempio incorporando una prova del lavoro) e infine il blocco viene archiviato 127 nella catena a blocchi con la transazione T scritta all’interno.
Una possibile variante per l’algoritmo descritto per la ricostruzione di dB (variante multi-agente) consente la ricostruzione di dB solo mediante l’interazione del dongle 10 con molteplici interfacce hardware 11 ciascuna portante un diverso UIDH e dH. In tal caso, facendo riferimento alla Figura 4, S è generata dalla giustapposizione di UIDH1, UIDH2,...UIDHn e UIDD, consentendo in questo modo di contrassegnare una transazione solo dopo l’interazione avvenuta con esito positivo di tutte le interfacce hardware 11.
Un’altra possibile variante dell’algoritmo descritto per la ricostruzione di dB (variante di soglia multi-agente) consente la ricostruzione di dB quando almeno un sottogruppo di almeno m interfacce hardware 11 delle n interfacce hardware totali 11 inviano un messaggio al dongle. Il processo è simile a un sistema di voto dove una transazione su catena a blocchi viene generata solo se la maggioranza (definita dalla soglia m; più m è elevata, più è alto il livello di consenso tra le Unità HW a cui il dongle richiede di creare una transazione) delle Unità HW concorda sul suo contenuto. In questa variante UIDH1, UIDH2,...UIDHn non sono stringhe casuali ma sono stringhe pre-generate e assegnate all’interfaccia hardware 11 per mezzo di uno schema di condivisione di segreti (vale a dire uno Schema di Condivisione di Segreti di Shamir). Negli schemi di condivisione di segreti, un segreto P (generalmente una stringa casuale) viene convertito in n stringhe diverse; queste stringhe condividono una proprietà utile: se almeno m delle n sono note da un agente, è possibile che l’agente ricostruisca il segreto P originario. Nella variante di soglia multi-agente, un segreto P viene generato in modo casuale e usato come input per uno schema di condivisione di segreti. P viene pertanto trasformato in UIDH1, UIDH2,... e il segreto P può essere ricostruito nel dongle 10 non appena il dongle 10 riceve m diversi UIDHi. Ancora facendo riferimento alla Figura 4, il segreto P è usato per generare la stringa S mediante giustapposizione di P con UIDD. Nella variante di soglia multi-agente, conoscere tutti gli UIDHi non è sufficiente per ricostruire dB poiché manca UIDD.

Claims (17)

  1. RIVENDICAZIONI 1. Sistema di comunicazione di dati per trasferire dati da un’unità hardware a una catena di blocchi (12) o altro registro distribuito, comprendente: un’interfaccia hardware (11) per collegarsi all’unità hardware; un dispositivo (10) comprendente a sua volta un microcontrollore (80), un elemento di sicurezza (82) collegato al microcontrollore (80), un primo modulo di comunicazione (85), un protocollo di comunicazione per consentire al microcontrollore (80) di comunicare con l’interfaccia hardware (11) attraverso il primo modulo di comunicazione (85), in cui il microcontrollore (80) è atto a: leggere dati dall’unità hardware attraverso l’interfaccia hardware (11); generare una transazione corrispondente ai dati; generare in modo sicuro una chiave privata di catena a blocchi, dB, e archiviarla in un elemento di sicurezza (82); contrassegnare digitalmente la transazione per mezzo della chiave privata di catena a blocchi, dB; erogare la transazione contrassegnata, e in seguito eliminare la chiave privata di catena a blocchi, dB, dall’elemento di sicurezza (82).
  2. 2. Sistema secondo la rivendicazione 1, caratterizzato dal fatto che il microcontrollore (80) è atto a generate una chiave privata di catena a blocchi, dB, da parametri contenuti in parte nel dispositivo (10) stesso e in parte nell’interfaccia hardware (11).
  3. 3. Sistema secondo una o più delle rivendicazioni precedenti, caratterizzato dal fatto che comprende inoltre un secondo modulo di comunicazione (81) per il collegamento a un server remoto dove è ospitata una catena a blocchi (12) o un nodo di registro distribuito generico e per erogare direttamente la transazione contrassegnata nella catena a blocchi (12) o nel registro distribuito generico.
  4. 4. Sistema secondo una o più delle rivendicazioni precedenti, caratterizzato dal fatto che il protocollo di comunicazione per consentire al microcontrollore (80) di comunicare con almeno un’unità hardware attraverso i primi mezzi di comunicazione (85) è basato sul set di comandi Hayes.
  5. 5. Sistema secondo una o più delle rivendicazioni precedenti, caratterizzato dal fatto che l’elemento di sicurezza (82) comprende mezzi per l’archiviazione sicura (83) e un motore criptografico di hardware (84).
  6. 6. Sistema secondo una o più delle rivendicazioni precedenti, caratterizzato dal fatto che l’interfaccia hardware (11) comprende un’unità computazionale, mezzi di comunicazione atti a collegarsi al dispositivo (10) per scambiare dati e mezzi di memoria per archiviare i dati.
  7. 7. Sistema secondo la rivendicazione precedente, caratterizzato dal fatto che i mezzi di memoria sono mezzi di memoria sicuri.
  8. 8. Metodo per trasferire dati da un’unità hardware a una catena a blocchi (12) o altro registro distribuito con il sistema secondo una o più delle rivendicazioni precedenti, in cui è eseguita una fase di preparazione iniziale comprendente i seguenti passaggi: l’interfaccia hardware (11) genera e archivia una stringa di Identificativo Univoco, UIDH, una Chiave Privata, dH, e una Chiave Pubblica, QH; l’interfaccia hardware (11) sollecita il dispositivo (10) inviando un comando di preparazione e la Chiave Pubblica, QH, attraverso il primo modulo di comunicazione (85); il dispositivo (10) estrae (63) la chiave pubblica QH dell’interfaccia hardware (11); il dispositivo (10) genera (64) una Chiave Privata, dD, e una Chiave Pubblica, QD e le archivia nell’elemento di sicurezza (82); il dispositivo (10) invia (65) la Chiave Pubblica QD all’interfaccia hardware (11) e archivia (66) la Chiave Pubblica QH nell’elemento di sicurezza (82); il dispositivo (10) genera (67) una stringa di Identificativo Univoco UIDD e la archivia (68) nell’elemento di sicurezza (82).
  9. 9. Metodo secondo la rivendicazione precedente, in cui è eseguita una fase di prima transazione comprendente i seguenti passaggi: l’interfaccia hardware (11) invia un comando per iniziare una transazione su catena a blocchi al dispositivo (10) con un elemento di sicurezza preparato che non contiene un indirizzo di catena a blocchi dongle, QB; l’interfaccia hardware (11) e il dispositivo (10) cooperano per generare e scambiarsi in modo sicuro (70) una chiave segreta K, detta chiave segreta K essendo generata a partire dalle chiavi dD, QD, dH e QH; il dispositivo (10) decripta (71) il comando ricevuto usando la chiave segreta K ed estrae (72) l’Identificativo Univoco di interfaccia hardware, UIDH, e il messaggio, M, da inviare alla catena a blocchi (12); il dispositivo (10) legge la stringa di Identificativo Univoco, UIDD, dall’archiviazione sicura (82) e genera (73) a partire da UIDD e UIDH la chiave privata di catena a blocchi dB; il dispositivo (10) ricava (74) l’indirizzo di catena a blocchi, QB, dalla chiave privata di catena a blocchi dB e successivamente l’indirizzo di catena a blocchi, QB, è archiviato (75) nell’elemento di sicurezza (82); il dispositivo (10) genera (76) la transazione su catena a blocchi e la invia alla catena a blocchi; il dispositivo (10) elimina UIDH, dB, UIDD e QB.
  10. 10. Metodo secondo una o più delle rivendicazioni da 8 a 9, in cui è eseguita la n<esima >fase di transazione, quando n > 1, comprendente i seguenti passaggi: l’interfaccia hardware (11) invia un comando AT di catena a blocchi al dispositivo (10) con un elemento di sicurezza preparato che contiene l’indirizzo di catena a blocchi dongle, QB; l’interfaccia hardware (11) e il dispositivo (10) cooperano per generare e scambiarsi in modo sicuro (110) una chiave segreta K, detta chiave segreta K essendo generata a partire dalle chiavi dD, QD, dH e QH; il dispositivo (10) decripta (111) il comando ricevuto usando la chiave segreta K ed estrae (112) l’Identificativo Univoco di interfaccia hardware, UIDH, e il messaggio, M, da inviare alla catena a blocchi (12); il dispositivo (10) legge la stringa di Identificativo Univoco, UIDD, dall’archiviazione sicura (82) e genera (114), a partire da UIDD e UIDH la chiave privata di catena a blocchi dB; il dispositivo (10) ricava (114) l’indirizzo di catena a blocchi, QB, da dB; il dispositivo (10) confronta (115) l’indirizzo di catena a blocchi, QB, come calcolato nel passaggio precedente, con l’indirizzo di catena a blocchi, QB, archiviato nell’elemento di sicurezza (82); se gli indirizzi di catena a blocchi confrontati nel passaggio precedente differiscono, la transazione non viene generata (116), se gli indirizzi di catena a blocchi confrontati nel passaggio precedente combaciano, allora il dispositivo (10) genera (117) una transazione su catena a blocchi a partire dal messaggio M e dalla chiave privata di catena a blocchi dB; il dispositivo (10) elimina UIDH, dB, UIDD e QB.
  11. 11. Metodo secondo una o più delle rivendicazioni da 9 a 10, in cui il passaggio di generare (76, 117) una transazione su catena a blocchi è eseguito come segue: il dispositivo (10) estrae (120) dal messaggio M l’indirizzo, QT, della catena a blocchi che riceve la transazione; il dispositivo (10) estrae (121) dal messaggio M dati aggiuntivi, D, da includere nella transazione su catena a blocchi; il dispositivo (10) genera (122) una transazione su catena a blocchi, T, contrassegnando la tupla (QT,D) con dB.
  12. 12. Metodo secondo una o più delle rivendicazioni da 9 a 11, in cui il passaggio di generazione della chiave privata di catena a blocchi, dB, è eseguita mediante l’interazione del dispositivo (10) con molteplici interfacce hardware (11) ciascuna portante un diverso UIDH e dH.
  13. 13. Metodo secondo una o più delle rivendicazioni da 9 a 12, in cui il passaggio di generazione della chiave privata di catena a blocchi dB è eseguito solo quando un sottogruppo di almeno m interfacce hardware (11) delle n interfacce hardware totali (11) interagisce con il dispositivo (10).
  14. 14. Dispositivo (10) per trasferire dati da un’unità hardware a una catena di blocchi (12) o altro registro distribuito, comprendente: un microcontrollore (80), un elemento di sicurezza (82) collegato al microcontrollore (80), un primo modulo di comunicazione (85), un protocollo di comunicazione per consentire al microcontrollore (80) di comunicare con un’interfaccia hardware esterna (11) attraverso il primo modulo di comunicazione (85), in cui il microcontrollore (80) è atto a: leggere dati dall’unità hardware attraverso l’interfaccia hardware (11); generare una transazione corrispondente ai dati; generare in modo sicuro una chiave privata di catena a blocchi, dB, e archiviarla in un elemento di sicurezza (82); contrassegnare digitalmente la transazione per mezzo della chiave privata di catena a blocchi, dB; erogare la transazione contrassegnata, e in seguito eliminare la chiave privata di catena a blocchi, dB, dall’elemento di sicurezza (82).
  15. 15. Dispositivo (10) secondo la rivendicazione 15, caratterizzato dal fatto che il microcontrollore (80) è atto a generate una chiave privata di catena a blocchi, dB, da parametri contenuti in parte nel dispositivo (10) stesso e in parte nell’interfaccia hardware (11).
  16. 16. Dispositivo (10) secondo una o più delle rivendicazioni precedenti, caratterizzato dal fatto che comprende inoltre un secondo modulo di comunicazione (81) per il collegamento a un server remoto dove è ospitata una catena a blocchi (12) o un nodo di registro distribuito generico e per erogare direttamente la transazione contrassegnata nella catena a blocchi (12) o nel registro distribuito generico.
  17. 17. Dispositivo (10) secondo una o più delle rivendicazioni da 14 a 16, caratterizzato dal fatto che è prodotto nella forma di un dongle.
IT102018000011129A 2018-12-14 2018-12-14 Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain IT201800011129A1 (it)

Priority Applications (4)

Application Number Priority Date Filing Date Title
IT102018000011129A IT201800011129A1 (it) 2018-12-14 2018-12-14 Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain
US17/298,857 US11960613B2 (en) 2018-12-14 2019-12-13 System, device and method for securely transferring information from a hardware to a blockchain
EP19838952.0A EP3895044A1 (en) 2018-12-14 2019-12-13 System, device and method for securely transferring information from a hardware to a blockchain
PCT/IB2019/060750 WO2020121265A1 (en) 2018-12-14 2019-12-13 System, device and method for securely transferring information from a hardware to a blockchain

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT102018000011129A IT201800011129A1 (it) 2018-12-14 2018-12-14 Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain

Publications (1)

Publication Number Publication Date
IT201800011129A1 true IT201800011129A1 (it) 2020-06-14

Family

ID=65861630

Family Applications (1)

Application Number Title Priority Date Filing Date
IT102018000011129A IT201800011129A1 (it) 2018-12-14 2018-12-14 Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain

Country Status (4)

Country Link
US (1) US11960613B2 (it)
EP (1) EP3895044A1 (it)
IT (1) IT201800011129A1 (it)
WO (1) WO2020121265A1 (it)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111478772B (zh) * 2020-06-22 2020-10-16 杭州趣链科技有限公司 一种流水线友好的签名和验签方法、设备及存储介质
US20220141020A1 (en) * 2020-11-04 2022-05-05 Gwangju Institute Of Science And Technology Blockchain e-voting system and operating method thereof
CN115412367B (zh) * 2022-10-31 2022-12-27 清华大学 一种分布式协作方法、联防网关装置及电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2953290A1 (en) * 2014-06-06 2015-12-09 Gemalto SA Management of high number of unique keys by a secure element
US20180034625A1 (en) * 2014-12-12 2018-02-01 Nagravision S.A. Device keys protection
US20180101906A1 (en) * 2016-10-07 2018-04-12 The Toronto-Dominion Bank Secure element method for distributed electronic ledger
EP3413507A1 (en) * 2017-06-09 2018-12-12 Nokia Technologies Oy Electronic documents certification

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10523443B1 (en) * 2016-08-24 2019-12-31 Bruce Kleinman Devices, methods, and systems for cryptographic authentication and provenance of physical assets
US11816642B2 (en) * 2017-03-20 2023-11-14 Steven Victor Wasserman Blockchain digital currency: systems and methods for use in enterprise blockchain banking
US10528377B2 (en) * 2017-04-26 2020-01-07 Red Hat, Inc. Cooperative cloud infrastructure using blockchains for hardware ownership and access
FR3066666B1 (fr) * 2017-05-18 2020-07-03 Cassidian Cybersecurity Sas Procede de securisation d'une communication sans gestion d'etats
US20190205898A1 (en) * 2017-07-31 2019-07-04 Chronicled, Inc Decentralized confidential transfer system, method and device
US20190058709A1 (en) * 2017-08-16 2019-02-21 Telefonaktiebolaget Lm Ericsson (Publ) Tenant management method and system in a cloud computing environment
AU2018354975B2 (en) * 2017-10-27 2024-08-29 Tata Consultancy Services Limited System and method for blockchain coexistence
US11170092B1 (en) * 2017-12-14 2021-11-09 United Services Automobile Association (Usaa) Document authentication certification with blockchain and distributed ledger techniques
US20190266576A1 (en) * 2018-02-27 2019-08-29 Anchor Labs, Inc. Digital Asset Custodial System
US20190340586A1 (en) * 2018-05-04 2019-11-07 Smart Worldwide Financial Technology Conducting optimized cross-blockchain currency transactions using machine learning
US10764039B2 (en) * 2018-08-01 2020-09-01 The Toronto-Dominion Bank Dynamic generation and management of asymmetric cryptographic keys using distributed ledgers
WO2020053994A1 (ja) * 2018-09-12 2020-03-19 日本電気株式会社 情報処理装置、情報処理システム、メンバ特定方法、及びプログラムが格納された非一時的なコンピュータ可読媒体
US20200174990A1 (en) * 2018-11-29 2020-06-04 Anthony Turner Pratkanis Accountably Redactable Data Structures

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2953290A1 (en) * 2014-06-06 2015-12-09 Gemalto SA Management of high number of unique keys by a secure element
US20180034625A1 (en) * 2014-12-12 2018-02-01 Nagravision S.A. Device keys protection
US20180101906A1 (en) * 2016-10-07 2018-04-12 The Toronto-Dominion Bank Secure element method for distributed electronic ledger
EP3413507A1 (en) * 2017-06-09 2018-12-12 Nokia Technologies Oy Electronic documents certification

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Mastering bitcoin : [unlocking digital cryptocurrencies]", 20 December 2014, O'REILLY MEDIA, Beijing Cambridge Farnham Köln Sebastopol Tokyo, ISBN: 978-1-4493-7404-4, article ANDREAS M. ANTONOPOULOS: "Mastering Bitcoin - Unlocking Digital Cryptocurrencies", XP055306939 *
RELEASE: "Ledger Documentation Hub", 1 August 2017 (2017-08-01), XP055607219, Retrieved from the Internet <URL:https://buildmedia.readthedocs.org/media/pdf/ledger/stable/ledger.pdf> *

Also Published As

Publication number Publication date
US20220035932A1 (en) 2022-02-03
US11960613B2 (en) 2024-04-16
EP3895044A1 (en) 2021-10-20
WO2020121265A1 (en) 2020-06-18

Similar Documents

Publication Publication Date Title
TWI813677B (zh) 用於自動物件辨識及鑑認之方法及系統
CN113574913B (zh) 用于准备和执行对象认证的方法和系统
US11296897B2 (en) Composite security marking and methods and apparatuses for providing and reading same
RU2695487C1 (ru) Способ и система обеспечения взаимодействия устройств интернета вещей (iot)
WO2020000707A1 (zh) 基于区块链的防伪方法、系统、计算机设备和存储介质
JP5260523B2 (ja) 無線周波識別(rfid)認証およびそのための鍵配信システム
US11210658B2 (en) Constructing a distributed ledger transaction on a cold hardware wallet
US11640394B2 (en) Method, apparatuses and system for exchanging data between a distributed database system and devices
IT201800011129A1 (it) Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain
US20220070006A1 (en) Methods, devices and system for the security-protected provision of sets of data
CN102236773A (zh) 射频识别加密验证系统和方法
CA3178180A1 (en) Constructing a distributed ledger transaction on a cold hardware wallet
EP2996277B1 (en) Securing a crytographic device against implementation attacks
CN103580852A (zh) 嵌入式安全元件的初始化
US11412047B2 (en) Method and control system for controlling and/or monitoring devices
CN113961956B (zh) 标签化网络信息服务生成及应用方法、装置、设备、介质
CN103746815A (zh) 安全通信方法及装置
CN104200137A (zh) 一种保护java程序自身安全的方法
CN107408233B (zh) 用于安全追踪码生成、应用以及验证的系统
Schleiffer et al. Secure key management-a key feature for modern vehicle electronics
CN110852764A (zh) 一种基于区块链技术可防伪可追溯的产品标识装置及方法
CN107026729B (zh) 用于传输软件的方法和装置
US9806888B1 (en) System and method for data protection using dynamic tokens
RU2470470C2 (ru) Защита выполнения криптографического вычисления
CN109688584A (zh) 适用于资源受限网络节点的数据安全存储系统及方法