IT202000014509A1 - Metodo e relativa rete di telecomunicazione configurata per trasmissioni dati sicure - Google Patents

Metodo e relativa rete di telecomunicazione configurata per trasmissioni dati sicure Download PDF

Info

Publication number
IT202000014509A1
IT202000014509A1 IT102020000014509A IT202000014509A IT202000014509A1 IT 202000014509 A1 IT202000014509 A1 IT 202000014509A1 IT 102020000014509 A IT102020000014509 A IT 102020000014509A IT 202000014509 A IT202000014509 A IT 202000014509A IT 202000014509 A1 IT202000014509 A1 IT 202000014509A1
Authority
IT
Italy
Prior art keywords
node
data
data packet
network
block
Prior art date
Application number
IT102020000014509A
Other languages
English (en)
Inventor
Gabriele Edmondo Pegoraro
Original Assignee
Bitcorp S R L
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 Bitcorp S R L filed Critical Bitcorp S R L
Priority to IT102020000014509A priority Critical patent/IT202000014509A1/it
Priority to EP21743568.4A priority patent/EP4169233B1/en
Priority to PCT/IB2021/055250 priority patent/WO2021255630A1/en
Priority to US18/001,939 priority patent/US20230239155A1/en
Publication of IT202000014509A1 publication Critical patent/IT202000014509A1/it

Links

Classifications

    • 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • 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/3297Cryptographic 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 time stamps, e.g. generation of time stamps
    • 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)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Radio Relay Systems (AREA)

Description

METODO E RELATIVA RETE DI TELECOMUNICAZIONE
CONFIGURATA PER TRASMISSIONI DATI SICURE
DESCRIZIONE
CAMPO TECNICO
La presente invenzione si riferisce al settore delle telecomunicazioni. In maggiore dettaglio, le forme di realizzazione della presente invenzione presentano un metodo e una relativa rete di telecomunicazione configurata per trasmissioni dati sicure.
STATO DELL'ARTE
Nel settore delle telecomunicazioni ? da sempre sentita la necessit? di garantire la riservatezza delle informazioni scambiate tra due o pi? utenti della rete di telecomunicazione cos? come la necessit? di certificare l'origine di un'informazione ricevuta in modo da garantire che non siano avvenute intromissioni nello scambio di informazioni e/o le informazioni scambiate non siano state alterate da una terza parte.
Come noto sono stati proposte svariate soluzioni per affrontare queste necessit?. Per esempio, la rete TOR cos? come i sistemi a rete virtuale privata (VPN) consento di scambiare pacchetti di dati mantenendo la privacy delle entit? che accedono a tali reti e dei dati scambiati.
US 2015/0058933 propone una tecnica per stabilire un canale di comunicazione sicuro tra un primo computer e un secondo computer attraverso una rete informatica. La tecnica prevede che sia inizialmente abilitato un modo di comunicazione sicura presso il primo computer senza che l'utente debba immettere alcuna informazione di cifratura per stabilire il canale di comunicazione sicuro. Successivamente, ? stabilito il canale di comunicazione sicuro tra il primo computer e il secondo computer attraverso la rete informatica. In particolare, il canale di comunicazione sicuro ? un canale di una rete virtuale privata stabilita attraverso la rete informatica in cui uno o pi? valori di dati che variano secondo una sequenza semi-casuale sono inseriti in ciascuno dei pacchetti dati.
Tuttavia, per costruzione tali reti riducono sensibilmente la velocit? di trasferimento dati (per esempio, valutata in termini di bitrate) attraverso la rete. Inoltre, l'accesso a e il trasferimento di file (per esempio, file multimediali) da un archivio remoto (per esempio, un repository) pu? esporre temporaneamente informazioni sull'entit? che effettua tale accesso o trasferimento, riducendo di conseguenza la sicurezza conferita da tali reti.
Nell'ultimo decennio lo sviluppo della tecnologia blockchain - basata su un registro digitale (ledger) condiviso tra pi? entit? di una rete informatica ? ha portato alla possibilit? di certificare in modo inalterabile una transazione digitale tra pi? entit? della rete informatica.
Per esempio, US 2018/0048738 propone che dispositivi di una rete di telecomunicazione wireless implementino una blockchain distribuita tra i dispositivi. In dettaglio, una stazione base della rete riceve, da un dispositivo mobile, una comunicazione radio contenente informazioni associate a una transazione di una blockchain. La stazione base converte tali informazioni sulla transizione di una blockchain in un formato basato su un protocollo internet. Successivamente, la stazione base aggiorna la blockchain propagando alle altre stazioni base della rete di telecomunicazione wireless l'informazione formattata secondo il protocollo internet attraverso una rete basata su protocollo internet interna alla rete di telecomunicazione wireless.
La soluzione proposta da US 2018/0048738 consiste sostanzialmente nello sfruttare le risorse computazionali delle stazioni base della rete di telecomunicazione wireless per la gestione e l'aggiornamento dinamico delle copie dei registri digitali condivisi della blockchain dei dispositivi mobili connessi alle stazioni base della rete di telecomunicazione wireless.
Inoltre, nella tecnica sono stati proposti diverse soluzioni basate sulla tecnologia blockchain volte a certificare l'identit? di entit? della rete coinvolte in una transazione o a certificare la transazione stessa, per certificare la correttezza dei dati scambiati e/o di un'entit? della rete informatica.
Per esempio, US 2017/0324738 propone un sistema di sicurezza Internet configurato per fornire risorse di sicurezza basate su una 'Internet Blockchain'. In dettaglio, la Internet Blockchain pu? essere utilizzata per consentire ad 'attori' internet come registri internet, entit? DNS, sistemi autonomi (ASes) e simili, di verificare il possesso di risorse internet come indirizzi IP, numeri AS, prefissi IP, nomi a dominio DNS e simili da parte di uno specifico attore internet. Inoltre, la Internet Blockchain consente di verificare transizioni relative a risorse internet come l'allocazione di indirizzi IP, di numeri AS, prefissi IP, nomi a dominio DNS e simili richiesti da attori internet.
Tale sistema opera in generale ai livelli superiori del modello ISO/OSI ? in generale dal livello di trasporto o superiore ? e si basano quindi sulla struttura TCP/IP per il trasferimento dei pacchetti dati ai livelli inferiori.
Diversamente, WO 2019/229612 della medesima Richiedente propone metodi e sistemi per il trasferimento di dati in modo cifrato e certificato per mezzo di un protocollo che prevede la presenza di un registro digitale distribuito che genera indirizzi di mittente e destinatario per stabilire una comunicazione in cui sia il contenuto sia il canale sono cifrati.
Per quanto i metodi e sistemi proposti in WO 2019/229612 permettano di ottenere una comunicazione sicura e affidabile, la sua implementazione risulta complessa e richiede dispositivi dotati di risorse hardware elevate.
SCOPI E RIASSUNTO DELL'INVENZIONE
? scopo della presente invenzione quello di superare gli inconvenienti dell?arte nota.
In particolare ? scopo della presente invenzione fornire un metodo di comunicazione tra nodi di una rete di telecomunicazione che permetta il trasferimento di pacchetti dati in modo sicuro attraverso un canale di comunicazione cifrato con costo computazionale e una latenza contenuti.
Un ulteriore scopo della presente invenzione ? quello di proporre un metodo di comunicazione tra nodi della rete di telecomunicazione che permetta di associare ai pacchetti dati trasmessi dai nodi della rete un'indicazione temporale sostanzialmente inalterabile in modo dinamico, in particolare in modo decentralizzato, ossia senza la necessit? di implementare un nodo certificatore o altra entit? analoga nella rete di telecomunicazione.
Un ulteriore scopo della presente invenzione ? quello di proporre un metodo di comunicazione tra nodi della rete di telecomunicazione in cui l'ordine temporale delle trasmissioni dei pacchetti dati ? certificato tramite un registro digitale condiviso indipendente dal canale di trasmissione dei pacchetti dati.
Questi e altri scopi della presente invenzione sono raggiunti mediante un sistema incorporante le caratteristiche delle rivendicazioni allegate, le quali formano parte integrante della presente descrizione.
In particolare, secondo un primo aspetto, la presente invenzione ? diretta a un metodo di comunicazione tra nodi di una rete di telecomunicazione, in cui ciascun nodo mantiene una copia di un registro digitale condiviso. Il metodo prevede che ciascun nodo mittente di un pacchetto dati esegua i passi di: a. identificare un nodo ricevitore a cui trasmettere detto pacchetto dati, b. generare il pacchetto dati da recapitare a un nodo destinatario, c. trasmettere al nodo ricevitore il pacchetto dati,
d. emettere una richiesta ai nodi della rete di registrare detta trasmissione del pacchetto dati sul registro digitale condiviso, e
quando ? ricevuto un pacchetto dati, il metodo prevede che ciascun nodo ricevitore, diverso dal nodo destinatario del pacchetto dati, reiteri almeno i passi a., e c.
Vantaggiosamente, il metodo ulteriormente prevede di:
e. generare ricorsivamente un blocco dati del registro digitale condiviso, ciascun blocco dati essendo identificato da un numero di conteggio progressivo e da un valore di hash calcolato attraverso un algoritmo di hashing che prevede l'esecuzione sequenziale di un numero predeterminato di operazioni, e f. registrare la trasmissione del pacchetto dati nel blocco dati per il quale il valore di hash ? in fase di calcolo al momento dell'emissione della richiesta di registrazione della trasmissione del pacchetto dati.
Grazie a tale soluzione ? possibile certificare in modo sostanzialmente inalterabile un istante di generazione di ciascun pacchetto dati trasmesso attraverso la rete di telecomunicazione. Infatti, una volta registrata la trasmissione in un blocco dati l'ordine di quest'ultimo nel registro digitale condiviso fornisce un'indicazione certa del istante di tempo di trasmissione e un ordine del pacchetto dati all'interno di una sequenza di pacchetti dati. Questo rende sostanzialmente impossibile per una terza parte alterare o sostituire un pacchetto trasmesso da un nodo della rete a un altro. Infatti, le registrazioni delle trasmissioni dei pacchetti dati sono contenute in un corrispondente blocco dati del registro digitale condiviso, pertanto inalterabile da una terza parte a meno di controllare almeno pi? di met? dei nodi della rete di telecomunicazione. Inoltre, la generazione del valore di hash per mezzo dell'algoritmo di hashing a operazioni sequenziali garantisce che non sia possibile prevedere o anticipare il valore di hashing utilizzando un hardware con prestazioni maggiore dei nodi della rete.
In una forma di realizzazione, l'algoritmo di hashing prevede di eseguire un numero predeterminato di iterazioni di un algoritmo di cifratura, ciascuna iterazione dell'algoritmo di cifratura ricevendo in ingresso il risultato dell'iterazione precedente.
Opzionalmente, l'algoritmo di hashing pu? ricevere in ingresso un valore associato al pacchetto dati di cui si desidera registrare la trasmissione nel blocco dati in elaborazione.
Preferibilmente, l'algoritmo di cifratura ? un algoritmo di cifratura SHA-2 o, ancora pi? preferibilmente, ? un algoritmo di cifratura SHA-3.
In questo modo ? possibile ottenere un algoritmo di cifratura a operazioni sequenziali particolarmente efficace.
In una forma di realizzazione, il passo di generare ricorsivamente un blocco dati del registro digitale condiviso prevede che ciascun nodo:
- inserisca un nuovo blocco dati nella propria copia del registro digitale condiviso dopo avere verificato la congruenza del nuovo blocco dati con i precedenti blocchi dati fornendo in ingresso a un algoritmo di verifica il valore di hash, associato al nuovo blocco, detto algoritmo di verifica essendo eseguibile in un tempo di verifica inferiore a un tempo di esecuzione dell'algoritmo di hashing.
Implementando come indicato la procedura di verifica ? possibile verificare velocemente la correttezza dei blocchi dati da inserire nel registro digitale condiviso. In particolare, la procedura di verifica non richiede l'utilizzo di una pluralit? di processori in parallelo per essere eseguita velocemente, pertanto risulta eseguibile in modo rapido anche su dispositivi portatili con capacit? hardware limitate.
Grazie a questa soluzione, ciascun blocco dati pu? essere verificato velocemente dai nodi della rete.
In particolare, l'algoritmo di cifratura e l'algoritmo di verifica consentono di elaborare i blocchi dati con tempistiche tali da gestire un flusso di pacchetti dati adatto a stabilire un servizio di messaggistica istantanea, una comunicazione voce o video.
In una forma di realizzazione, l'algoritmo di hashing e l'algoritmo di verifica sono algoritmi di una funzione a ritardo verificabile (Verifiable Delay Function).
In questo modo ? possibile ottenere un registro digitale condiviso basato su una proof of history (PoH) sicura e verificabile velocemente.
In una forma di realizzazione, la richiesta di registrazione della trasmissione del pacchetto dati comprende:
- almeno un'informazione di trasmissione relativa al pacchetto dati trasmesso, comprendente almeno uno tra:
- un codice identificativo del nodo mittente;
- un codice identificativo del nodo destinatario;
- un codice identificativo del pacchetto dati trasmesso, e
- una sequenza di pacchetti dati cui il pacchetto dati trasmesso appartiene.
Vantaggiosamente, il metodo prevede di memorizzare in una porzione del blocco dati detta almeno un'informazione sul pacchetto dati trasmesso.
Grazie a tale soluzione ? possibile identificare in modo affidabile a quale pacchetto dati si riferisca ciascuna registrazione di trasmissione memorizzata all'interno di un blocco dati.
Preferibilmente, il metodo prevede di:
- cifrare detta almeno un'informazione di trasmissione utilizzando una chiave di cifratura pubblica del nodo destinatario e/o
- firmare elettronicamente detta almeno un'informazione di trasmissione utilizzando una chiave di cifratura privata del nodo mittente.
In questo modo ? possibile garantire la riservatezza delle informazioni contenute nel registro digitale condiviso.
In una forma di realizzazione della presente invenzione, la richiesta di registrazione della trasmissione del pacchetto dati comprende:
- un valore di hash associato all'ultimo blocco dati compreso nelle copie del registro digitale al momento della trasmissione del pacchetto dati.
Includere il valore di hash associato all'ultimo blocco dati del registro digitale condiviso consente di avere una certificazione aggiuntiva a quella fornita dal valore di hash in cui la trasmissione del pacchetto dati ? registrata. Grazie a questa doppia informazione ? possibile garantire un ordine temporale dei pacchetti dati in modo ancora pi? preciso e affidabile. Allo stesso tempo, risulta anche incrementata la robustezza rispetto a tentativi di alterazione da terze parti.
In una forma di realizzazione, il metodo ulteriormente prevede che ciascun nodo: - rimuova dalla propria copia del registro digitale condiviso informazioni di trasmissione contenute nei blocchi dati relative a trasmissioni di un pacchetto dati per cui detto nodo non sia il nodo mittente o il nodo destinatario.
Per esempio, ciascuna informazione di trasmissione contenuta nei blocchi dati ? cifrata per mezzo di un primo codice di cifratura del destinatario e/o firmata digitalmente per mezzo di un secondo codice di cifratura del mittente.
Preferibilmente, il passo di rimuovere dalla propria copia del registro digitale condiviso informazioni di trasmissione contenute nei blocchi dati relative a trasmissioni di un pacchetto dati per cui detto nodo non sia il nodo mittente o il nodo destinatario prevede che detto nodo:
- rimuova dalla propria copia del registro digitale condiviso le informazioni di trasmissione non firmate con il proprio codice di cifratura, e
- rimuova dalla propria copia del registro digitale condiviso informazioni di trasmissione non decifrabili con una chiave privata associata al proprio codice di cifratura.
Grazie a questa soluzione ? possibile ridurre le dimensioni delle copie di registro digitale condiviso memorizzate dai vari nodi della rete di telecomunicazione senza perdere informazioni utili o corrispondenza tra le copie del registro digitale condiviso. Questo consente di ridurre i requisiti in termini di capacit? di archiviazione dei nodi della rete di telecomunicazione e riduce il tempo di acquisizione di una copia del registro digitale condiviso da parte di un nuovo nodo della rete di telecomunicazione.
In una forma di realizzazione, il metodo ulteriormente prevede che:
- il nodo mittente trasmetta una pluralit? di pacchetti dati al medesimo nodo destinatario iterando i passi a. ? d., e
- il nodo destinatario della pluralit? di pacchetti dati, ordini i pacchetti dati ricevuti in base alla posizione nel registro condiviso del blocco dati in cui ? registrata la trasmissione di ciascun pacchetto dati da parte del blocco mittente.
Il metodo permette quindi di ordinare una sequenza comprendente una pluralit? di pacchetti dati in modo indipendente dal contenuto del pacchetto dati e/o dal protocollo utilizzato per la trasmissione di tale pacchetto dati.
Un differente aspetto della presente invenzione riguarda una rete di telecomunicazione comprendente una pluralit? di nodi. Ciascun nodo comprende almeno un modulo di elaborazione dati, un modulo di memoria e un modulo di ricetrasmissione.
Vantaggiosamente ciascun nodo ? configurato per:
- mantenere una copia di un registro digitale condiviso, ed
- eseguire il metodo secondo una qualsiasi delle forme di realizzazione precedenti.
In particolare, ciascun nodo della rete di telecomunicazione comprende uno smartphone, un tablet, un computer, una stazione radio base, un evolution Node B, un modem o un router WiFi o un altro dispositivo analogo.
Ulteriori caratteristiche e scopi della presente invenzione appariranno maggiormente chiari dalla descrizione che segue.
BREVE DESCRIZIONE DEI DISEGNI
L?invenzione verr? descritta qui di seguito con riferimento ad alcuni esempi, forniti a scopo esplicativo e non limitativo, ed illustrati nei disegni annessi. Questi disegni illustrano differenti aspetti e forme di realizzazione della presente invenzione e, dove appropriato, numeri di riferimento illustranti strutture, componenti, materiali e/o elementi simili in differenti figure sono indicati da numeri di riferimento similari.
La Figura 1 ? una rappresentazione schematica di una rete di telecomunicazione secondo una forma di realizzazione della presente invenzione;
la Figura 2 ? uno schema a blocchi di un generico nodo della rete di telecomunicazione di Figura 1;
la Figura 3 un diagramma di flusso di una procedura di comunicazione tra nodi della rete di telecomunicazione della Figura 1 secondo una forma di realizzazione della presente invenzione
la Figura 4a ? una rappresentazione schematica di un database a grafo di un primo nodo della rete di telecomunicazione secondo una forma di realizzazione della presente invenzione;
la Figura 4a ? una rappresentazione schematica di un database a grafo di un secondo nodo della rete di telecomunicazione secondo una forma di realizzazione della presente invenzione;
la Figura 5 ? un diagramma di flusso di una procedura per determinare, attraverso il database a grafo di Figura 4a e 4b, un nodo ricevitore a cui trasmettere un pacchetto dati secondo una forma di realizzazione della presente invenzione;
la Figura 6 ? una rappresentazione schematica di un generico pacchetto dati scambiato tra nodi della rete secondo una forma di realizzazione della presente invenzione;
la Figura 7 ? una rappresentazione schematica di un generico registro digitale condiviso tra i nodi della rete di telecomunicazione della Figura 1;
la Figura 8 ? un diagramma di flusso di una procedura di generazione e aggiunta di un nuovo blocco dati al registro digitale condiviso di Figura 3 secondo una forma di realizzazione della presente invenzione;
la Figura 9 ? una rappresentazione schematica di un generico blocco dati del registro digitale condiviso di Figura 7 secondo una forma di realizzazione della presente invenzione;
la Figura 10 ? un diagramma di flusso di una procedura di popolazione di una lista di identificativi dei nodi della rete di telecomunicazione secondo una forma di realizzazione della presente invenzione;
la Figura 11 ? un diagramma di flusso di una procedura configurata per individuare una sequenza minima di nodi della rete di telecomunicazione necessaria a trasmettere un pacchetto dati da un nodo mittente a un nodo destinatario secondo una forma di realizzazione alternativa della presente invenzione, e
la Figura 12 ? una rappresentazione schematica di un database a grafo della rete di telecomunicazione secondo una forma di realizzazione alternativa della presente invenzione, utilizzato dalla procedura di Figura 11.
DESCRIZIONE DETTAGLIATA DELL?INVENZIONE
Mentre l?invenzione ? suscettibile di varie modifiche e costruzioni alternative, alcune forme di realizzazione preferite sono mostrate nei disegni e saranno descritte qui di seguito in dettaglio. Si deve intendere, comunque, che non vi ? alcuna intenzione di limitare l?invenzione alla specifica forma di realizzazione illustrata, ma, al contrario, l?invenzione intende coprire tutte le modifiche, costruzioni alternative, ed equivalenti che ricadano nell?ambito dell?invenzione come definito nelle rivendicazioni.
L?uso di ?ad esempio?, ?ecc.?, ?oppure? indica alternative non esclusive senza limitazione a meno che non altrimenti indicato. L?uso di ?include? significa ?include, ma non limitato a? a meno che non sia altrimenti indicato.
Con riferimento alla Figura 1, il riferimento 1 indica una rete di telecomunicazione ? abbreviata in 'rete' nel seguito ? secondo una forma di realizzazione della presente invenzione. La rete 1 comprende una pluralit? di nodi di rete, nove nodi di rete N1-N9 nell'esempio non limitativo considerato, in grado di scambiare informazioni attraverso segnali elettromagnetici, preferibilmente ? sebbene non limitativamente - per mezzo di onde elettromagnetiche.
Come illustrato in maggiore dettaglio in Figura 2, il generico nodo Nx della rete 1 (con x compreso tra 1 e 9 nell'esempio considerato) comprende un modulo di elaborazione 10 configurato per implementare uno o pi? algoritmi di elaborazione dati, un modulo di memoria 20 configurato per memorizzare dati e un modulo di ricetrasmissione 30 configurato per stabilire e gestire una o pi? connessioni con almeno un nodo della rete 1.
Per esempio, il modulo di elaborazione 10 comprendere uno o pi? processori, microprocessori, microcontrollori, ASIC, FPGA, DSP o simili. Il modulo di memoria 20 comprende uno o pi? elementi di memoria non-volatile e volatile adatti a memorizzare dati, preferibilmente in formato binario. Il modulo di ricetrasmissione 30 comprende almeno un modem per comunicazioni attraverso radiazioni elettromagnetiche (Wi-Fi, Bluetooth, GSM, UMTS, LTE/LTE-A, 5G, ecc.) e, opzionalmente un modem per comunicazioni cablate.
Preferibilmente, sebbene non limitativamente, il modulo di elaborazione 10 comprendere uno o pi? moduli aggiuntivi 40, per esempio, il nodo Nx pu? comprendere un modulo di interfaccia configurato per fornire dati e/o ricevere istruzioni da un'entit? esterna come un utente o un altro dispositivo, e in aggiunta o in alternativa un modulo di rilevazione comprendente uno o pi? sensori, selezionati tra sensori di movimento ? come uno o pi? tra accelerometri, giroscopi, sensori di gravit?, ecc. ?, sensori di posizione ? come uno o pi? tra magnetometri, un sistema di rilevazione GNSS, ecc. ? e sensori ambientali ? come uno o pi? tra barometri, fotometri, termometri, microfoni, fotocamere, sensori di prossimit?, ecc., e sensori biometrici ? come un lettore di impronte digitali.
Naturalmente, il generico nodo Nx della rete 1 comprende una circuiteria di potenza (non illustrata) configurata per alimentare i moduli 10 ? 40 del nodo Nx e, eventuale, circuiteria ancillare necessaria al corretto funzionamento dei moduli Il generico nodo Nx della rete 1 comprende, ma non ? limitato a: uno smartphone, un tablet, un personal computer, una stazione radio base, un eNodeB, un modem wireless e simili.
Nella forma di realizzazione considerata, il generico nodo Nx della rete 1 memorizza un codice identificativo IDx che permette di identificare univocamente il nodo Nx nella rete. Preferibilmente, il codice identificativo IDx ? un valore di hash che rappresenta un indirizzo pubblico associato a una chiave cifratura privata corrispondente a un secondo valore di hash ? in modo analogo all'indirizzo pubblico e alla chiave privata di un portafoglio per criptovaluta.
In una forma di realizzazione preferita, il codice identificativo i quali sono attribuiti al nodo Nx da un'entit? di registrazione IDx e la corrispondente chiave di cifratura privata sono generate e assegnate al nodo Nx da un'entit? di registrazione ER quando ? eseguita una richiesta di inserimento nella rete 1 da parte del nodo Nx. Opzionalmente, l'entit? di registrazione ER ? anche configurata per operare come un nodo della rete 1. Per esempio, l'entit? di registrazione ER ? implementata da un server remoto accessibile tramite una connessione basata su protocollo TCP/IP sicuro.
Inoltre, il generico nodo Nx memorizza una lista Rx di uno o pi? codici identificativi associati a rispettivi nodi della rete 1 con cui ha scambiato dati in passato o scambia dati abitualmente.
Infine, il generico nodo Nx della rete 1 mantiene ? memorizza e aggiorna - una copia di un registro digitale condiviso Lx, il quale sar? indicato come 'registro' nel seguito per brevit?.
Vantaggiosamente, il generico nodo Nx esegue un'applicazione software AS configurata per gestire lo scambio di informazioni attraverso una rete da pari a pari, o peer-to-peer (P2P) al fine di consentire lo scambio di informazioni tra nodi della rete 1 attraverso la trasmissione dei pacchetti dati e il mantenimento del registro Lx secondo le procedure descritte nel seguito.
I nodi N1-N9 della rete 1 sono configurati per scambiare dati tra loro, preferibilmente raggruppati in pacchetti dati dp, eseguendo una procedura 100 di ricetrasmissione in accordo con una forma di realizzazione della presente invenzione e illustrata schematicamente dal diagramma di flusso di Figura 3. Tipicamente, un'informazione da comunicare ? rappresentata da una pluralit? di dati binari i quali sono suddivisi in porzioni di informazione sequenziali, ciascuna delle quali ? trasmessa in un corrispondente pacchetto dati. L'informazione pu? essere quindi ricostruita estraendo le porzioni di informazione dai pacchetti dati ricevuti e ordinandole nel corretto ordine.
A titolo di esempio, nel seguito si far? riferimento alla trasmissione di un pacchetto dati dp da parte del nodo N1 al nodo N9, sfruttando il nodo N3 come ricevitore intermediario (illustrato schematicamente in Figura 1 per mezzo di frecce tratteggiate).
La procedura 100 ha inizio quando un'applicazione in esecuzione su un primo nodo della rete 1 ? il nodo N1 nell'esempio considerato ? richiede un trasferimento di un'informazione a un secondo nodo della rete 1 ? il nodo N9 nell'esempio considerato (blocco di inizio 101).
La procedura 100 prevede di selezionare un nodo N1-N9 della rete 1 cui trasferire il pacchetto dati dp (blocco 103) tra i nodi compresi il cui codice identificativo ID1-ID9 ? compreso nella lista R1 del nodo N1 mittente.
Preferibilmente, la selezione permette di ottenere una sequenza di nodi della rete che permetta di recapitare un pacchetto dati al nodo N9 destinatario attraverso una corrispondente sequenza di trasmissioni del pacchetto dp dati da un nodo a un altro nodo che assicuri una bassa latenza e un consumo di energia ridotto. Ancor pi? preferibilmente, la procedura 100 permette di utilizzare la sequenza minima di nodi della rete che permette di recapitare il pacchetto dati dp al nodo N9 destinatario attraverso un numero minimo di trasmissioni del pacchetto dp dati da un nodo a un altro nodo.
Nella forma di realizzazione preferita, il nodo a cui sia da trasferire il pacchetto dati dp sopra menzionata ? identificato per mezzo di un database a grafo DBG1-DGB9 riferito al corrispondente nodo N1-N9, di cui i database a grafo DBG1 e DBG3 relativi ai nodi N1 e N3 sono illustrati schematicamente nelle Figure 4a e 4b.
Nella forma di realizzazione considerata, il nodo N1-N9 a cui trasmettere il pacchetto dp ? selezionato implementando una procedura di selezione nodo 200 (illustrata in Figura 5). In dettaglio, la procedura 200, una volta avviata (blocco di avvio 201) prevede di popolare il database a grafo DBG1 riferito al nodo N1 mittente ? o, nelle iterazioni successive, un database a grafo DBG2-DBG8 di un nodo N2-N8 ricevitore intermediario ? che deve trasmettere il pacchetto dati dp. Il generico database a grafo DBGx ? popolato in modo che ogni nodo del database a grafo DBGx comprenda un nodo N1-N9 il cui codice identificativo ID1-ID9 ? memorizzato nella lista Rx del generico nodo Nx considerato e che ogni arco colleghi il generico nodo Nx a un rispettivo nodo N1-N9 il cui codice identificativo ID1-ID9 ? memorizzato nella lista Rx del generico nodo Nx (blocco 203). Nell'esempio di Figura 4a, il database a grafo DBG1 del nodo N1 mittente comprende i nodi N2, N3, N5, N7 e N8 i cui codici identificativi ID2, ID3, ID5, ID7 e ID8 sono contenuti memorizzati nella lista R1 del nodo N1 mittente, mentre in Figura 4b il database a grafo DBG3 del nodo N3 ricevitore comprende i nodi N1, N4, N6 e N9 i cui codici identificativi ID1, ID4, ID6 e ID9 sono memorizzati nella lista R3 del nodo N3 ricevitore.
Vantaggiosamente, la procedura 200 prevede di rilevare un'indicazione della posizione P1-P9 attuale del corrispondente nodo N2-N9 di rete 1 associati a un nodo database a grafo DBG1 del nodo N1 (blocco 205). Preferibilmente, l'indicazione di posizione P1-P9 ? aggiunta al corrispondente nodo del database a grafo DBG1.
Per esempio, l'indicazione di posizione comprende uno o pi? tra: una posizione geografica misurata attraverso un sistema satellitare di navigazione globale (GNSS), un'informazione relativa a una cella di rete cellulare in cui ? attestato il nodo N1-N9 (nel caso di un dispositivo mobile), un indirizzo IP associato al nodo N1-N9, un Access Point Name (APN, nome di punto d'accesso) cui ? collegato il nodo di rete, un dato di geolocalizzazione (geolocation o geotag) associato al nodo N1-N9 da servizi di geomessaging, geomarketing, ecc. utilizzati. A tale scopo, le istanze dell'applicazione software AS in esecuzione sul generico nodo Nx ? configurata per acquisire l'indicazione di posizione P1-P9 riferita al rispettivo nodo Nx e renderla disponibile a un altro nodo N1-N9 della rete 1 che ne faccia richiesta. In alternativa, l'applicazione software AS in esecuzione sul generico nodo Nx ? configurata per rilevare e trasmettere, preferibilmente periodicamente, l'indicazione di posizione P1-P9 attuale a ciascun nodo N1-N9 il cui codice identificativo ID1-ID9 ? memorizzato nella lista Rx del generico nodo Nx considerato.
Opzionalmente, la procedura 200 prevede di rilevare una capacit? S1-S9 attuale di stabilire un canale di comunicazione per ricevere e/o inoltrare il pacchetto dati dp da parte di ciascun nodo N1-N9 della rete 1 associato a un corrispondente nodo del database a grafo DBG1 (blocco 207). Preferibilmente, tale indicazione di capacit? S1-S9 ? aggiunta al corrispondente nodo del database a grafo DBG1.
Successivamente, la procedura 200 prevede di selezionare un nodo ricevitore determinare tra i nodi del database DBG1 cui trasferire il pacchetto dati dp (blocco 209). Nella forma di realizzazione preferita, ? selezionato ? come nodo ricevitore ? il nodo con una distanza minima dal nodo centrale ? ossia il nodo N1 mittente - del database a grafo DBG1. Nell'esempio di Figura 4a, il nodo a distanza minima corrisponde al nodo N3 di rete. In generale, il nodo a distanza minima ? identificato confrontando le indicazioni di posizione P2-P9 associate ai nodi del database a grafo DBG1 con l'indicazione di posizione P1 associata al nodo centrale del database a grafo DBG1, ossia il nodo N1 mittente, e identificando il nodo a una distanza minore rispetto agli altri. Con "distanza" nella presente si intende una misura (per esempio, una misura lineare) o un insieme di misure (per esempio, un insieme di misure/vettori in un sistema di coordinate cartesiano o polari) che permetta di determinare una separazione spaziale tra due nodi della rete. Pi? in generale, con "distanza" si fa riferimento a una separazione tra due nodi che richiede un tempo non nullo per trasmettere un pacchetto dati da un nodo all'altro. In questo caso, il nodo a distanza minima ? il nodo che comporta il ritardo temporale inferiore per essere raggiunto da un pacchetto dati. Ad ogni modo, la distanza minima assicura che la trasmissione del pacchetto dati da un nodo all'altro avvenga all'interno di un intervallo di tempo di timeout, quindi, senza richiedere ritrasmissioni del pacchetto dati.
Determinato il percorso minimo, la procedura 200 prevede di verificare che sia effettivamente possibile instaurare un canale di comunicazione con il nodo selezionato (blocco decisionale 211). In dettaglio, la procedura 200 prevede di verificare la capacit? S3 a stabilire un canale di comunicazione del nodo N3 a distanza minore.
In caso negativo (ramo di uscita N del blocco 211), il nodo a distanza minore ? scartato (blocco 213) e la procedura 200 prevede di selezionare un nuovo percorso minimo reiterando i passi sopra descritti a partire dal blocco 209.
Diversamente, il nodo N3 a distanza minore ? considerato utilizzabile (ramo di uscita Y del blocco 211) e la procedura 200 prevede, prima, di fornire in uscita il codice identificativo associato al nodo N3 della rete 1 (blocco 215) per la prosecuzione della procedura 100 e, quindi, terminare (al blocco di fine 217).
Determinato il nodo N3 a cui trasmettere, la procedura 100 prevede di generare il pacchetto dati dp (illustrato schematicamente in Figura 6) comprendente almeno una porzione dell'informazione da trasmettere al nodo N9 destinatario (blocco 105). Nell'esempio considerato in Figura 5, il pacchetto dati dp comprende un'intestazione, o header HR, e un carico utile, o payload PL.
L'header HR comprende un campo mittente ID-M in cui ? riportato il codice identificativo ID1 del nodo N1 mittente del pacchetto dati dp, un campo destinatario ID-D in cui ? riportato il codice identificativo ID9 del nodo N9 destinatario del pacchetto dati dp, un campo di ricevitore ID-R in cui ? riportato il codice identificativo del nodo a cui deve essere effettivamente trasmesso il pacchetto e, opzionalmente, una marca temporale TS indicativa di un istante di tempo della generazione del pacchetto dati dp misurata dal nodo N1 mitemente ? per esempio, attraverso un orologio interno del relativo modulo di elaborazione 10. In particolare, la procedura 100 prevede di inserire nel campo di ricevitore ID-R il codice identificativo del nodo N3 selezionato per mezzo della procedura 200 sopra descritta. Il payload PL del pacchetto dati dp comprende invece l'informazione o, pi? tipicamente, una porzione dell'informazione da trasmettere. Preferibilmente, almeno il payload PL del pacchetto dati dp ? cifrato con il codice identificativo del nodo N9 destinatario in modo che il suo contenuto sia decifrabile al solo nodo N9 destinatario.
Generato il pacchetto dati dp, esso ? trasmesso dal nodo N1 mittente al nodo, N3 nell'esempio considerato, il cui codice identificativo ID3 ? compreso nel campo nodo di ricevitore ID-R (blocco 107). In generale, il pacchetto dati ? codificato in una radiazione elettromagnetica irradiata dal modulo di ricetrasmissione 30 del nodo N1 mittente.
Inoltre, la procedura 100 prevede che sia effettuata una richiesta di registrazione della trasmissione del pacchetto dati dp in un blocco dati Bn delle copie del registro L1-L9 mantenute dai nodi N1-N9 della rete 1 (blocco 109). In dettaglio, i nodi N1-N9 della rete 1 condividono i dati contenuti nelle copie del registro L1-L9 instaurando una struttura di tipo pari a pari, o peer-to-peer (P2P) sostanzialmente in accordo con la tecnologia di registro digitale condiviso o Distributed Ledger Technology (DLT), come indicato nel seguito.
Ricevuta tale richiesta di registrazione, i nodi N1-N9 della rete 1 registrano la trasmissione del pacchetto dati dp all'interno del blocco dati Bn in fase di generazione al momento di ricezione della richiesta di registrazione da parte del nodo N1 (blocco 111). In particolare, la generica copia del registro Lx comprende una pluralit? di blocchi dati Bn, Bn-1, Bn-2, Bn-3, ecc. a partire da un blocco dati di origine B0, i quali sono concatenati tra loro in ordine cronologico, in modo da formare una struttura di dati inalterabile, come illustrato schematicamente in Figura 7. In particolare, nella presente con 'inalterabile' si intende che una volta aggiunto un blocco dati Bn al registro Lx non ? possibile apportare modifiche ai dati contenuti nel blocco dati Bn e/o in uno dei blocchi precedenti del registro Lx senza invalidare l'intera struttura dati. In dettaglio, ciascun blocco ? contraddistinto da un'intestazione o header HB che contiene un valore di hash Hn univoco associato al blocco dati Bn, un valore di hash Hn-1 associato al blocco dati Bn-1 precedente nella catena di blocchi che forma il registro distribuito Lx, e un valore di conteggio Cn crescente al crescere della posizione del blocco dati Bn nella catena di blocchi del registro Lx. Inoltre, il blocco dati Bn comprende un corpo BD in cui sono memorizzate una o pi? registrazioni di trasmissione rdp.
Nella forma di realizzazione considerata, la registrazione delle transazioni all'interno dei blocchi dati Bn del registro L1-L9 avviene attraverso una procedura 300 di registrazione? di cui la Figura 8 ? un diagramma di flusso. La procedura 300 prevede di generare un nuovo blocco dati Bn del registro Lx applicando un protocollo di proof-of-history (prova storica) il quale permette di certificare un ordine temporale di creazione e aggiunta del blocco dati Bn al registro Lx (blocco 301). In dettaglio, ciascun blocco ? generato quando un generico nodo Nx della rete 1 calcola il valore di hash Hn del blocco dati Bn per mezzo di un algoritmo hashing fH (per esempio basata sulla famiglia di algoritmi di cifratura SHA-2 o SHA-3) a partire da un valore di hash Hn-1 associato al blocco dati Bn-1 precedente nella catena di blocchi che forma il registro distribuito Lx e, eventualmente, uno o pi? valori aggiuntivi.
Nelle forme di realizzazione della presente invenzione, l'algoritmo di hasing fH richiede almeno un tempo di hashing tH minimo per essere eseguito su una parallel random-access machine (PRAM) avente un numero di processori p predeterminato. In dettaglio, la funzione di hashing fH implementata prevede l'esecuzione in modo sequenziale ? non parallelizzabile ? di un numero predeterminato di operazioni. Per esempio, l'algoritmo di hashing fH comprende N iterazioni di un algoritmo di cifratura SHA-2, pi? preferibilmente SHA-3, ciascuna iterazione dell'algoritmo ricevendo come ingresso almeno valore di hashing calcolato all'iterazione precedente. Di conseguenza, il tempo di hashing tH necessario all'esecuzione della funzione di hashing fH da un qualsiasi nodo N1-N9 della rete 1 corrisponde alla somma dei tempi necessari per l'esecuzione di ciascuna di tali operazioni.
Diversamente, lo hash Hn pu? essere verificato per mezzo di un algoritmo di verifica vH in un tempo di verifica tv molto inferiore al tempo di hashing tH. Preferibilmente, l'algoritmo di verifica vH pu? essere eseguito sfruttando un'elaborazione in parallelo su pi? processori.
L'algoritmo di hasing fH e l'algoritmo di verifica vH adatti all'impiego nelle forme di realizzazione possono essere definiti come algoritmi di valutazione e di verifica, rispettivamente, di una funzione a ritardo verificabile o Verifiable Delay Function definita in accordo con Dan Boneh, Joseph Bonneau, Benedikt B?nz, Ben Fisch: "Verifiable Delay Functions" Advances in Cryptology ? CRYPTO 2018, Volume 10991.
La procedura 300 prevede di inserire nel corpo BD del blocco dati Bn, in via di generazione, una o pi? registrazioni di trasmissione per cui ? ricevuta una richiesta durante il tempo di hashing tH del blocco dati Bn (blocco 303).
La richiesta di registrazione della trasmissione del pacchetto dati dp comprende un'informazione sul pacchetto dati dp e, opzionalmente, il valore di hash Hn-1 dell'ultimo blocco dati Bn-1 compreso nelle copie del registro L1-L9 al momento della trasmissione del pacchetto dati dp. Per esempio, l'informazione sul pacchetto dati dp comprende uno tra, preferibilmente entrambi, i codici identificativi ID1 e ID9 di del nodo mittente N1 e destinatario N9, e in aggiunta o in alternativa un codice identificativo del pacchetto dati dp e/o di una sequenza di pacchetti dati cui il pacchetto dati dp appartiene. Ancor pi? preferibilmente, le informazioni contenute nella richiesta di registrazione sono cifrate per mezzo del codice identificativo ID9 del nodo N9 destinatario e/o firmate per mezzo del codice identificativo ID1 del nodo N1 mittente. In questo modo, una volta generato il blocco dati Bn ciascuna registrazione di trasmissione rdp memorizzata nel corpo BD risulta associata in modo inalterabile al valore di hash Hn e al valore di conteggio Cn del blocco dati Bn, fornendo quindi un'indicazione temporale certa della trasmissione del corrispondente pacchetto dati dp.
Il blocco dati Bn cos? generato ? aggiunto alle copie del registro L1-L9 dopo essere stato verificato ? per mezzo dell'algoritmo di verifica vH - dai nodi N1-N9 della rete 1 (blocco 305).
La procedura 300 prevede quindi di reiterare i passi sopra descritti a partire dal blocco 301 per generare un nuovo blocco dati Bn+1 il cui valore di hash Hn+1 ? calcolato a partire dal valore d hash Hn del blocco dati Bn.
Tornando alla procedura 100, il pacchetto dati dp trasmesso ? ricevuto dal nodo indicato nel campo ricevitore ID-R ? il nodo N3 nel caso considerato ? (blocco 113) ed ? verificato se tale nodo della rete 1 corrisponde al nodo N9 destinatario (blocco decisionale 115).
In caso negativo (ramo di uscita N del blocco 115), la procedura 100 prevede di reiterare i passi precedenti a partire dalla determinazione di un database a grafo DBG3 ? illustrato in Figura 4b ? di cui il nodo N3 ricevitore ? il nodo centrale in modo da determinare un nuovo nodo N1-N9 a cui trasmettere il pacchetto (blocco 103, procedura 200), modificare il campo ricevitore ID-R del pacchetto dati dp inserendo il codice identificativo ID1-ID9 associato al nodo N1-N9 identificato (blocco 105) e quindi trasmettere il pacchetto dati dp allo stesso (blocco 107) richiedendo (blocco 109), al contempo, la registrazione della trasmissione in un nuovo blocco del registro L1-L9 (che avviene come descritto in relazione al blocco 111 e alla procedura 300) e controllare nuovamente se il pacchetto dati dp ? stato ricevuto dal nodo N9 destinatario (blocchi 113 e 115).
Quando il pacchetto dati dp ? ricevuto dal nodo N9 destinatario (ramo di uscita Y del blocco 115) ? dopo la trasmissione effettuata dal nodo N3 ricevitore nell'esempio considerato ?, la procedura 100 prevede che sia identificata un'informazione temporale associata al pacchetto dp attraverso la copia del registro L9 memorizzata dal nodo N9 destinatario (blocco 117). Preferibilmente, ? previsto di identificare il blocco dati Bn ? in particolare il corrispondente valore di conteggio Cn ? in cui ? registrata la trasmissione del pacchetto dati dp effettuata dal nodo N1 mittente. Grazie a questa informazione il nodo N9 destinatario ? in grado di identificare la posizione del pacchetto dati dp all'interno di una sequenza di pacchetti dati trasmessi dal nodo N1 e quindi ricostruire correttamente l'informazione comunicata dal nodo N1 mittente.
Preferibilmente, la procedura 100 prevede che il nodo N9 destinatario generi e trasmetta un pacchetto di risposta rp per confermare la ricezione del pacchetto dati dp (blocco 119). In generale, il pacchetto di risposta rp (illustrato schematicamente in Figura 9) comprende un'intestazione, o header HR, e un carico utile, o payload PL. L'header HR comprende un campo mittente ID-M in cui ? riportato il codice identificativo ID1 del nodo N9 mittente del pacchetto di risposta rp, un campo destinatario ID-D in cui ? riportato il codice identificativo ID1 del nodo N1 destinatario del pacchetto di risposta rp, un campo di ricevitore ID-R in cui ? riportato il codice identificativo di un nodo ricevitore a cui deve essere effettivamente trasmesso il pacchetto e, opzionalmente, una marca temporale TS indicativa di un istante di tempo della generazione del pacchetto di risposta dp misurata dal nodo N9 mitemente. Il payload PL del pacchetto dati dp comprende invece un riferimento al pacchetto dati dp ricevuto. In particolare, la procedura 100 prevede di inserire nel campo di ricevitore ID-R il codice identificativo di un nodo N1-N9 della rete 1 selezionato per mezzo della procedura 200 sopra descritta ? il quale potr? essere differente dal nodo N3 utilizzato per la trasmissione del pacchetto dati dp. In modo analogo a quanto descritto sopra, il pacchetto di risposta rp sar? trasmesso tra uno o pi? nodi della fino a raggiungere il nodo N1 mittente del pacchetto dati dp in modo analogo a quanto sopra descritto in relazione ai blocchi 103 ? 107 e qui non ripetuto per brevit?.
Nella forma di realizzazione considerata, diversamente da quanto descritto per i pacchetti dati dp, per il pacchetto di risposta rp non ? richiesta la registrazione sulla della trasmissione nelle copie del registro L1-L9.
Una volta che il nodo N1 mittente del pacchetto dati dp riceve il corrispondente pacchetto di risposta rp (blocco 121), la procedura 100 prevede di verificare se vi siano uno o pi? altri pacchetti dati dp' da trasmettere (blocco decisionale 123). In caso affermativo (ramo Y del blocco 123) la procedura 100 prevede di reiterare i passi sopra descritti a partire da quanto descritto in relazione al blocco 103 per trasferire un nuovo pacchetto dati dp'. Diversamente, se non vi sono altri pacchetti dati dp' da trasmettere (ramo N del blocco 123), la procedura 100 termina (blocco di termine 125.)
? tuttavia chiaro che gli esempi sopra riportati non devono essere interpretati in senso limitativo e l?invenzione cos? concepita ? suscettibile di numerose modifiche e varianti.
Per esempio, in una forma di realizzazione alternativa, ? previsto che ciascun nodo N1-N9 elimini dal corpo dei blocchi dati B0, ?, Bn+1 della propria copia del registro digitale condiviso L1-L9 le registrazioni di trasmissioni riferite a trasmissioni in cui non ha agito da nodo mittente o da nodo destinatario. Per esempio, ciascun nodo ? configurato per eliminare le registrazioni di trasmissione che non ? in grado di decifrare per mezzo della propria chiave privata o che non sono firmati per mezzo del proprio codice identificativo.
Ancora, nulla vieta di prevedere una diversa procedura (non illustrata) in cui ? richiesta la registrazione della sola prima trasmissione di ciascun pacchetto dati dal nodo mittente verso un altro nodo ? a prescindere dal fatto che tale nodo sia il nodo destinatario o un nodo ricevitore.
Diversamente, nulla vieta di implementare una procedura alternativa (non illustrata), in cui ? prevista la registrazione di una o pi? trasmissioni del pacchetto di risposta trasmesso dal nodo destinatario del pacchetto dati al nodo mittente dello stesso.
Sebbene, l'utilizzo di database a grafo e il protocollo di proof-of-history sinergicamente consentono di ottenere una struttura di comunicazione a pacchetti con una latenza contenuta, tale da permettere una comunicazione rapida e affidabile tra due o pi? nodi della rete, nulla vieta che in forme di realizzazione alternative della presente invenzione, al posto del database a grafo sia utilizzato un differente sistema per identificare una sequenza di nodi che permettano di effettuare una trasmissione dati, per esempio un database relazionale.
In una forma di realizzazione illustrata in Figura 10, l'entit? di registrazione ER prevede di eseguire una procedura 400 di popolazione della lista Rx di codici identificativi memorizzata dal generico nodo Nx al momento della registrazione i quest'ultimo nella rete 1.
La procedura 400 ? avviata quando il generico nodo Nx richiede l'inserimento nella rete 1 e, contestualmente, la generazione del rispettivo codice identificativo IDx e della chiave di cifratura privata associata (blocco di inizio 401).
La procedura prevede di analizzare una lista dei contatti memorizzata nel nodo Nx (blocco 403) ? per esempio, la rubrica telefonica e/o una lista di indirizzi di posta elettronica noti nel caso di un dispositivo mobile ? e verificare se a uno dei contatti registrati in tale lista ? associato un nodo della rete 1 (blocco 405). Per esempio, l'entit? di registrazione ER ? configurata per verificare se uno o pi? dei contatti compresi nella lista contatti del nodo Nx ? associato a un corrispondente codice identificativo ID1-ID9 della rete. A tale scopo, l'entit? di registrazione ER mantiene e aggiorna un elenco dei nodi della rete 1; preferibilmente, ciascuna voce dell'elenco comprende un codice identificativo ID1-ID9 e almeno un altro elemento identificatore del nodo Nx di rete ? per esempio, un indirizzo di posta elettronica, un numero di telefono / codice IMSI, un codice IMEI del telefono o un codice MAC di un modem, o altri elementi identificatori simili associati al ai nodi N1-N9 di rete 1. L'entit? di registrazione ER ? configurata per verificare la presenza di uno di tali elementi identificatori nella lista contatti del nodo Nx.
Per ogni corrispondenza trovata, ? previsto di comunicare al nodo Nx il codice identificativo ID1-ID9 associato a un nodo N1-N9 riconducibile a un contatto della lista contatti del nodo Nx (blocco 407) e quindi la procedura termina (al blocco di termine 409).
La procedura 400 consente di instaurare canali di comunicazione in modo semplice nella rete 1 e consente di comunicare in modo efficace a un generico nodo Nx non appena quest'ultimo entra a fare parte della rete 1.
Come sar? evidente alla persona esperta, ? possibile prevedere passi opzionali volti ad abilitare su richiesta l'accesso alla lista contatti compresa nei vari nodi della rete e/o a consentire la distribuzione dei codici identificativi in modo da garantire il controllo al possessore del nodo dei dati analizzati o forniti dall'entit? di registrazione ER.
In una variante (non illustrata) della procedura 100, ? previsto di abilitare nodi temporanei di rete. In dettaglio, un generico nodo temporaneo ? un dispositivo con caratteristiche analoghe alle caratteristiche dei nodi sopra descritte e dotato dell'applicazione software, ma a cui non sia stato assegnato un codice identificativo. Nella variante della procedura 100, nel caso non sia individuato un nodo della rete entro la distanza utile da un nodo mittente, ? previsto di verificare se uno dei contatti compresi nella lista contatti del nodo mittente ? in grado di operare da nodo temporaneo e se sia entro la distanza utile. In caso affermativo, la variante della procedura prevede che sia assegnato un codice identificativo temporaneo al nodo temporaneo in modo da abilitarlo alla ricetrasmissione dei pacchetti dati. Una volta avvenuta la ricetrasmissione del pacchetto dati, il nodo temporaneo ? rimosso dalla rete ? e il codice identificativo temporaneo ? rimosso dall'elenco dell'entit? di registrazione.
Grazie a tale soluzione ? possibile garantire una maggiore copertura della rete, in particolare durante una fase iniziale di attivazione della rete o per garantire un funzionamento della rete anche in caso di traffico elevato.
Naturalmente, nulla vieta di utilizzare il codice identificativo ID1-ID9 e la chiave privata come un portafoglio per criptovalute in aggiunta alle funzioni sopra descritte. In questo modo, la rete 1 pu? gestire transazioni economiche in parallelo alla trasmissione dei pacchetti dati, senza la necessit? di implementare modifiche sostanziali.
In forme di realizzazione alternative (non illustrate), la cifratura delle informazioni nei pacchetti dati e/o delle informazioni nei blocchi del registro digitale condiviso, cos? come la firma digitale delle stesse, possono essere eseguite utilizzando codici di cifratura differenti tra loro e, in generale, differenti dal codice identificativo del nodo di rete cui sono destinate o che genera tali informazioni.
In generale, ogni blocco dati del registro digitale condiviso registra la trasmissione di un solo pacchetto dati appartenente alla medesima sequenza di pacchetti dati generati e trasmessi da un nodo mittente verso il medesimo nodo destinatario. Tuttavia, nulla vieta che in forme di realizzazione alternative (non illustrate) il medesimo blocco registri due o pi? trasmissioni di altrettanti pacchetti dati trasmessi da un medesimo nodo mittente al medesimo nodo destinatario. In tale caso, il nodo destinatario ordiner? tali pacchetti dati ? la cui registrazione ? inclusa nel medesimo blocco dati - in funzione del valore della marca temporale contenuta nell'intestazione di tali pacchetti. In aggiunta o in alternativa, ciascuna trasmissione registrata pu? essere associata all'ultimo valore di hash calcolato da un'iterazione dell'algoritmo di cifratura dell'algoritmo di hashing al momento della registrazione della trasmissione.
Come sar? evidente alla persona esperta, pi? nodi della rete possono trasmettere pacchetti dati in parallelo e, in modo analogo, pi? nodi della rete possono ricevere pacchetti dati in parallelo. In altre parole, pi? istanze delle procedure 100 e 200 possono essere eseguite in parallelo all'interno della rete ciascuna per gestire la trasmissione di uno o pi? pacchetti dati tra corrispondenti nodi mittenti e nodi destinatari. Inoltre, nulla vieta di prevedere varianti della procedura 100 in cui i nodi della rete operano in modo da trasmettere pacchetti dati in modalit? multicast o broadcast.
In una differente forma di realizzazione (non illustrata), ? prevista una procedura di selezione nodo modificata. Secondo tale procedura modificata, nel caso il codice identificativo del nodo destinatario sia compreso nella lista del nodo mittente, ? previsto di trasmettere direttamente il pacchetto dati direttamente al nodo destinatario anche se quest'ultimo non ? il nodo pi? vicino al nodo mittente. In dettaglio, la procedura modificata prevede di verificare che il nodo destinatario sia entro una distanza utile dal nodo mittente ? per esempio, entro una portata massima a cui il nodo mittente pu? trasmettere il pacchetto dati - e trasmettere il pacchetto al nodo destinatario dati in caso affermativo. Se al contrario il nodo destinatario non ? entro la distanza utile del nodo mittente la procedura modificata esegue i medesimi passi sopra descritti in relazione alla procedura 200.
In aggiunta o in alternativa una forma di realizzazione alternativa, prevede di implementare una procedura 500 di selezione nodo alternativa (illustrata dal diagramma di flusso di Figura 11) che prevede di identificare il percorso minimo di nodi che permette di collegare il nodo mittente al nodo destinatario. In questo caso, la procedura 500, una volta avviata (blocco di avvio 501) prevede di generare un database a grafo di rete DBGr - illustrato schematicamente in Figura 12 ? in cui ogni nodo del database a grafo DBGr corrisponde a un nodo N1-N9 della rete 1 e ogni arco collega tra loro due nodi quando i rispettivi codici identificativi ID1-ID9 sono memorizzati nelle corrispondenti liste R1-R9 (blocco 503). Nell'esempio di Figura 11, per semplicit?, sono illustrati unicamente gli archi che collegano il nodo N1 mittente ai nodi N2, N3, N5, N7 e N8 i cui codici identificativi ID2, ID3, ID5, ID7 e ID8 sono contenuti memorizzati nella lista R1 del nodo N1 mittente e gli archi associati ai nodi N3, N5 e N6 che permettono di stabilire un percorso tra il nodo N1 mittente e il nodo N9 destinatario.
Successivamente, la procedura alternativa 500 prevede di determinare il percorso pi? breve nel database a grafo DBG che permette di collegare il nodo N1 mittente al nodo N9 destinatario (blocco 505). In altre parole, ? selezionato il percorso che attraversa il numero minore di archi e nodi del database a grafo DBG che collega il nodo N1 mittente al nodo N9 destinatario. In generale, il percorso minimo ? identificato verificando iterativamente a partire da nodo N1 mittente, se esiste un arco del database a grafo DBGr che collega il nodo N1-N8 considerato con il nodo N9 destinatario e, in caso negativo, passando a esaminare i nodi N2-N8 connessi per mezzo di archi connessi ai nodi N2-N8 a loro volta connessi al nodo precedentemente considerato fino ad individuare un arco che connette un nodo N2-N8 della rete 1 con il nodo N9 destinatario. Tra l'uno o pi? percorsi possibili individuati ? selezionato come percorso minimo il percorso che comprende il minore numero di nodi e archi che collegano il nodo N1 mittente al nodo N9 destinatario ? il percorso N1-N3-N9 nell'esempio considerato, indicato da archi realizzati con linee continue in Figura 12.
Determinato il percorso minimo, la procedura alternativa 500 prevede di verificare che sia effettivamente possibile instaurare un canale di comunicazione attraverso i nodi N1-N9 della rete 1 compresi nel percorso minimo (blocco decisionale 507). In dettaglio, la procedura alternativa 500 prevede di verificare che i nodi N1-N9 della rete 1 compresi nel percorso minimo siano compresi in una regione di comunicazione utile. Per esempio, ? verificato che ciascun nodo N1-N9 della rete 1 compreso nel percorso minimo si trovi entro la distanza utile del nodo N1-N9 della rete 1 precedente del percorso minimo ? sulla base delle indicazioni di posizioni P1-P9 acquisite. Opzionalmente, la procedura 400 prevede di verificare anche che ciascun nodo N1-N9 della rete 1 compreso nel percorso minimo sia disponibile a stabilire un canale di comunicazione ? sulla base delle indicazioni di capacit? S1-S9 acquisite.
In caso negativo (ramo di uscita N del blocco 507), il percorso minimo determinato ? scartato (blocco 509) e la procedura alternativa 500 prevede di selezionare un nuovo percorso minimo reiterando i passi sopra descritti a partire dal blocco 505.
Diversamente, il percorso minimo ? considerato utilizzabile (ramo di uscita Y del blocco 507) e la procedura alternativa 500 prevede di fornire in uscita il codice identificativo ID2-ID9 del primo nodo ricevitore ? il nodo N3 nell'esempio considerato ? successivo al nodo N1 mittente nella sequenza di nodi minima cos? determinata (blocco 511) per la prosecuzione della procedura 100 e quindi terminare (al blocco di fine 513).
In aggiunta o in alternativa, la procedura 200 o la procedura alternativa 500 anzich? generare ogni volta il database a grafo DBG1-9 di ciascun nodo o il database a grafo complessivo DBGr prevedono ? durante iterazioni successive a una prima iterazione ? di aggiornare tali database a grafo DBG1-9 o DBGr, per aggiungere o rimuovere nodi e modificare le indicazioni di posizione o capacit? in base allo stato attuale dei nodi della rete 1.
Naturalmente, uno o pi? passi delle procedure 100, 200, 300, 400 e 500 sopra descritti possono essere eseguiti in parallelo tra loro ? come i passi relativi ai blocchi 107 e 109; 203, 205 e/o 209, e 301 e 303 ? o con un ordine differente da quello sopra presentato. In particolare, sar? evidente che la procedura 300 ? implementata sostanzialmente in parallelo ai passi della procedura 100 e della procedura 200/500 durante l'operazione della rete di telecomunicazione.
In alternativa, il nodo mittente pu? essere configurato per trasmettere una richiesta di connessione al nodo destinatario, la quale contenente il codice identificativo ID9, ai nodi del database a grafo cui ? connesso. Tale richiesta quale ? propagata nel grafo fino a raggiungere il nodo N9 che emette un messaggio di risposta. Quando il nodo mittente riceve un primo messaggio di risposta trasmette il pacchetto dati al nodo adiacente che gli ha inviato il messaggio di risposta.
Analogamente, uno o pi? passi opzionali possono essere aggiunti o rimossi da uno o pi? delle procedure sopra descritte. Per esempio, la procedura 100 pu? prevedere passi aggiuntivi in cui ? monitorato un tempo di timeout a partire da un istante di trasmissione di un corrispondente pacchetto dati, nel caso in cui non sia ricevuto un relativo pacchetto di risposta entro tale tempo di timeout, la trasmissione del pacchetto ? considerata fallita e il pacchetto dati deve essere ritrasmesso.
Ancora, nulla vieta di interrompere un tentativo di trasmissione di pacchetto dati e generare un segnale di errore in caso non sia possibile individuare un nodo disponibile a ricevere e, eventualmente, inoltrare il pacchetto dati o una sequenza di nodi della rete disponibili a operare da nodi ricevitori o non si trovino nodi della rete entro la regione di comunicazione utile di uno o pi? nodi della sequenza.
Inoltre, nulla vieta di configurare i nodi della rete per modificare la tecnologia di trasmissione di un medesimo pacchetto dati tra due differenti nodi della rete al fine di garantire la trasmissione del pacchetto dati dal nodo mittente al nodo destinatario. Per esempio, un generico pacchetto dati pu? essere inizialmente trasmesso in accordo con lo standard LTE tra una prima coppia di nodi, quindi secondo lo standard WiFi Direct o Bluetooth tra una o pi? seconde coppie di nodi ricevitori intermedi e, infine, secondo lo standard UMTS tra un nodo ricevitore e il nodo destinatario. In particolare, nel caso di una rete di telecomunicazione wireless, tali trasmissioni comprendono in generale sia trasmissioni di tipo da dispositivo (mobile) a dispositivo (mobile), indicate come device-to-device (D2D), sia trasmissioni da dispositivo mobile a stazione radio base, router, o simili.
Inoltre, come sar? evidente alla persona esperta, le procedure 100, 200, 300, 300 e 500 secondo varie forme di realizzazione della presente invenzione sono opportunamente combinabili in modo da costituire sostanzialmente un metodo che garantisce la ricetrasmissione di pacchetti dati tra nodi della rete in modo sicuro con una struttura di tipo P2P, in particolare sostanzialmente invulnerabile ad attacchi di tipo uomo-nel-mezzo (man-in-the-middle) e in grado di mantenere la riservatezza delle informazioni scambiate.
In particolare, il metodo secondo la presente invenzione ? in grado di supportare in modo efficace uno o pi? tra servizi di messaggistica istantanea, comunicazioni voce e video.
Naturalmente, tutti i dettagli sono sostituibili da altri elementi tecnicamente equivalenti.
In conclusione, i materiali impiegati, nonch? le forme e le dimensioni contingenti dei dispositivi, apparati e terminali sopra menzionati potranno essere qualsiasi secondo le specifiche esigenze implementative senza per questo uscire dall?ambito di protezione delle seguenti rivendicazioni.

Claims (10)

RIVENDICAZIONI
1. Metodo (100, 200, 300, 400, 500) di comunicazione tra nodi di una rete di telecomunicazione, ciascun nodo mantenendo una copia di un registro digitale condiviso,
il metodo (100, 200, 300, 400, 500) prevedendo che ciascun nodo mittente di un pacchetto dati esegua i passi di:
a. identificare (103; 200, 500) un nodo ricevitore a cui trasmettere detto pacchetto dati,
b. generare (105) il pacchetto dati da recapitare a un nodo destinatario, c. trasmettere (107) al nodo ricevitore il pacchetto dati,
d. emettere (109) una richiesta ai nodi della rete di registrare detta trasmissione del pacchetto dati sul registro digitale condiviso, e
quando ? ricevuto un pacchetto dati, il metodo prevede che ciascun nodo ricevitore, diverso dal nodo destinatario del pacchetto dati, reiteri almeno i passi a., e c.,
caratterizzato dal fatto che
il metodo (100, 200, 300, 400, 500) ulteriormente prevede di:
e. generare (111, 301) ricorsivamente un blocco dati del registro digitale condiviso, ciascun blocco dati essendo identificato da un numero di conteggio progressivo e da un valore di hash calcolato attraverso un algoritmo di hashing che prevede l'esecuzione sequenziale di un numero predeterminato di operazioni, e
f. registrare (111, 305) la trasmissione del pacchetto dati nel blocco dati per il quale il valore di hash ? in fase di calcolo al momento dell'emissione della richiesta di registrazione della trasmissione del pacchetto dati.
2. Il metodo (100, 200, 300, 400, 500) secondo la rivendicazione 1, in cui l'algoritmo di hashing prevede di eseguire un numero predeterminato di iterazioni di un algoritmo di cifratura, ciascuna iterazione dell'algoritmo di cifratura ricevendo in ingresso il risultato dell'iterazione precedente.
3. Il metodo (100, 200, 300, 400, 500) secondo la rivendicazione 1 o 2, in cui il passo di generare (111, 301) ricorsivamente un blocco dati del registro digitale condiviso prevede che ciascun nodo:
- inserisca un nuovo blocco dati nella propria copia del registro digitale condiviso dopo avere verificato la congruenza del nuovo blocco dati con i precedenti blocchi dati fornendo in ingresso a un algoritmo di verifica il valore di hash, associato al nuovo blocco, detto algoritmo di verifica essendo eseguibile in un tempo di verifica inferiore a un tempo di esecuzione dell'algoritmo di hashing.
4. Il metodo (100, 200, 300, 400, 500) secondo la rivendicazione 2, in cui l'algoritmo di hashing e l'algoritmo di verifica sono algoritmi di una funzione a ritardo verificabile.
5. Il metodo (100, 200, 300, 400, 500) secondo una qualsiasi delle rivendicazioni precedenti, in cui la richiesta di registrazione della trasmissione del pacchetto dati comprende:
- almeno un'informazione di trasmissione relativa al pacchetto dati trasmesso, comprendente almeno uno tra:
- un codice identificativo del nodo mittente;
- un codice identificativo del nodo destinatario;
- un codice identificativo del pacchetto dati trasmesso, e
- una sequenza di pacchetti dati cui il pacchetto dati trasmesso appartiene, e
in cui il metodo prevede di memorizzare in una porzione del blocco dati detta almeno un'informazione sul pacchetto dati trasmesso.
6 Il metodo (100, 200, 300, 400, 500) secondo la rivendicazione 5, in cui il metodo prevede di:
- cifrare detta almeno un'informazione di trasmissione utilizzando una chiave di cifratura pubblica del nodo destinatario e/o
- firmare elettronicamente detta almeno un'informazione di trasmissione utilizzando una chiave di cifratura privata del nodo mittente.
7 Il metodo (100, 200, 300, 400, 500) secondo la rivendicazione 5 o 6, in cui la richiesta di registrazione della trasmissione del pacchetto dati comprende:
- un valore di hash associato all'ultimo blocco dati compreso nelle copie del registro digitale condiviso al momento della trasmissione del pacchetto dati.
8. Il metodo (100, 200, 300, 400, 500) secondo una qualsiasi delle rivendicazioni precedenti, ulteriormente prevedendo che ciascun nodo della rete: - rimuova dalla propria copia del registro digitale condiviso informazioni di trasmissione relative a un pacchetto dati di cui detto nodo non sia il nodo mittente o il nodo destinatario.
9. Il metodo (100, 200, 300, 400, 500) secondo una qualsiasi delle rivendicazioni precedenti, ulteriormente prevedendo che:
- il nodo mittente trasmetta una pluralit? di pacchetti dati al medesimo nodo destinatario iterando i passi a. ? d., e
- il nodo destinatario della pluralit? di pacchetti dati, ordini (117) i pacchetti dati ricevuti in base alla posizione nel registro condiviso del blocco dati in cui ? registrata la trasmissione di ciascun pacchetto dati da parte del nodo mittente.
10. Rete di telecomunicazione (1) comprendente una pluralit? di nodi (N1-N9), ciascun nodo comprendendo almeno un modulo di elaborazione dati (10), un modulo di memoria (20) e un modulo di ricetrasmissione (30), laddove ciascun nodo (N1-N9) ? configurato per:
- mantenere una copia di un registro digitale condiviso (L1-L9), ed
- eseguire il metodo (100, 200, 300, 400, 500) secondo uno qualsiasi delle rivendicazioni precedenti da 1 a 9.
IT102020000014509A 2020-06-17 2020-06-17 Metodo e relativa rete di telecomunicazione configurata per trasmissioni dati sicure IT202000014509A1 (it)

Priority Applications (4)

Application Number Priority Date Filing Date Title
IT102020000014509A IT202000014509A1 (it) 2020-06-17 2020-06-17 Metodo e relativa rete di telecomunicazione configurata per trasmissioni dati sicure
EP21743568.4A EP4169233B1 (en) 2020-06-17 2021-06-15 Method and corresponding telecommunication network for secure data transmissions
PCT/IB2021/055250 WO2021255630A1 (en) 2020-06-17 2021-06-15 Method and corresponding telecommunication network for secure data transmissions
US18/001,939 US20230239155A1 (en) 2020-06-17 2021-06-15 Method and corresponding telecommunication network for secure data transmissions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT102020000014509A IT202000014509A1 (it) 2020-06-17 2020-06-17 Metodo e relativa rete di telecomunicazione configurata per trasmissioni dati sicure

Publications (1)

Publication Number Publication Date
IT202000014509A1 true IT202000014509A1 (it) 2021-12-17

Family

ID=72801786

Family Applications (1)

Application Number Title Priority Date Filing Date
IT102020000014509A IT202000014509A1 (it) 2020-06-17 2020-06-17 Metodo e relativa rete di telecomunicazione configurata per trasmissioni dati sicure

Country Status (4)

Country Link
US (1) US20230239155A1 (it)
EP (1) EP4169233B1 (it)
IT (1) IT202000014509A1 (it)
WO (1) WO2021255630A1 (it)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170324738A1 (en) 2016-05-03 2017-11-09 Alcatel-Lucent Usa Inc. Internet security
US20180048738A1 (en) 2016-08-15 2018-02-15 Red Hat, Inc. Blockchain management using a device in a wireless telecommunication system
US20190334697A1 (en) * 2018-04-27 2019-10-31 Gulfstream Aerospace Corporation Communication nodes, distributed communication networks, and methods for monitoring communication in a communication network using blockchains
WO2019229612A1 (en) 2018-05-28 2019-12-05 PERSURICH, Christian Fabio Method, architecture and devices for the realization of an encrypted communication protocol of encrypted data packets named 'transport encrypted protocol' (tep)

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170324738A1 (en) 2016-05-03 2017-11-09 Alcatel-Lucent Usa Inc. Internet security
US20180048738A1 (en) 2016-08-15 2018-02-15 Red Hat, Inc. Blockchain management using a device in a wireless telecommunication system
US20190334697A1 (en) * 2018-04-27 2019-10-31 Gulfstream Aerospace Corporation Communication nodes, distributed communication networks, and methods for monitoring communication in a communication network using blockchains
WO2019229612A1 (en) 2018-05-28 2019-12-05 PERSURICH, Christian Fabio Method, architecture and devices for the realization of an encrypted communication protocol of encrypted data packets named 'transport encrypted protocol' (tep)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DAN BONEHJOSEPH BONNEAUBENEDIKT BUNZBEN FISCH: "Reliable Delay functions''advances in Cryptology", CRYPTO, vol. 10991, 2018
DAN BONEHJOSEPH BONNEAUBENEDIKT BUNZBEN FISCH: "Reliable Delay functions''advances in Cryptology", CRYPTO, vol. 10991, 2018, XP002801992 *

Also Published As

Publication number Publication date
WO2021255630A1 (en) 2021-12-23
EP4169233A1 (en) 2023-04-26
US20230239155A1 (en) 2023-07-27
EP4169233B1 (en) 2024-05-29

Similar Documents

Publication Publication Date Title
CN106664561B (zh) 用于确保预关联服务发现安全的系统和方法
AU2018322689B2 (en) Terminal identity protection method in a communication system
CN101960814B (zh) Ip地址委派
JP6018511B2 (ja) サーバ装置、グループ鍵通知方法及びそのプログラム
CN111381962B (zh) 一种边缘服务迁移方法及装置
JP2018523369A (ja) ハッシュ木ベースのデータ署名を処理するための方法及び機器
CN113873453B (zh) 通信方法、装置、系统及介质
EP3701667A1 (en) Anonymity system for goods delivery
Iqbal et al. Efficient and dynamic access control mechanism for secure data acquisition in IoT environment
CN111771390A (zh) 自组织网络
US9949119B2 (en) Method and system for assessing a message in a decentralized communication network
IT202000014509A1 (it) Metodo e relativa rete di telecomunicazione configurata per trasmissioni dati sicure
CN116170144A (zh) 智能电网匿名认证方法、电子设备及存储介质
IT202000014518A1 (it) Metodo e relativa rete di telecomunicazione configurata per trasmissioni dati sicure basata su database a grafo
CN114584383B (zh) 一种基于区块链的物联网设备匿名身份认证方法
US20230222491A1 (en) Systems and methods for transfer of non-fungible assets across multiple blockchain systems
Grabatin et al. Self-sovereign identity management in wireless ad hoc mesh networks
US11902270B2 (en) Method for preparing usage data for relays used during a communication between two devices and for searching for the data and associated devices
CN116998132A (zh) 经由装置标识符组合引擎(dice)实现蜂窝网络存取
KR102134429B1 (ko) 컨텐츠 검증 방법 및 장치
Singh et al. Lightweight multilevel key management scheme for large scale wireless sensor network
EP3808119A1 (en) A technique for authenticating data transmitted over a cellular network
CN117714203B (zh) 一种无线安全保密网关的实现方法
Bagula et al. On the Relevance of Using Multi-layered Security in the Opportunistic Internet-of-Things
JP2006173735A (ja) メッセージの認証方法と該認証方法を用いたメッセージ認証装置およびメッセージ認証システム