DPKI: eliminare le carenze della PKI centralizzata utilizzando blockchain

Non è un segreto che uno degli strumenti ausiliari comunemente utilizzati, senza il quale la protezione dei dati nelle reti aperte è impossibile, è la tecnologia dei certificati digitali. Tuttavia, non è un segreto che il principale svantaggio della tecnologia sia la fiducia incondizionata nei centri che emettono certificati digitali. Il direttore della tecnologia e dell'innovazione presso ENCRY Andrey Chmora ha proposto un nuovo approccio all'organizzazione infrastrutture a chiave pubblica (Infrastruttura a chiave pubblica, PKI), che contribuirà a eliminare le attuali carenze e che utilizza la tecnologia di contabilità distribuita (blockchain). Ma prima le cose principali.

Se hai familiarità con il funzionamento della tua attuale infrastruttura a chiave pubblica e ne conosci le principali carenze, puoi passare a ciò che proponiamo di modificare di seguito.

Cosa sono le firme e i certificati digitali?L'interazione su Internet implica sempre il trasferimento di dati. Abbiamo tutti interesse a garantire che i dati vengano trasmessi in modo sicuro. Ma cos’è la sicurezza? I servizi di sicurezza più richiesti sono riservatezza, integrità e autenticità. A questo scopo vengono attualmente utilizzati metodi di crittografia asimmetrica, ovvero crittografia a chiave pubblica.

Partiamo dal fatto che per utilizzare questi metodi, i soggetti di interazione devono avere due chiavi individuali accoppiate: pubblica e segreta. Con il loro aiuto vengono forniti i servizi di sicurezza sopra menzionati.

Come viene garantita la riservatezza del trasferimento delle informazioni? Prima di inviare i dati, l'abbonato mittente crittografa (trasforma crittograficamente) i dati aperti utilizzando la chiave pubblica del destinatario e il destinatario decrittografa il testo cifrato ricevuto utilizzando la chiave segreta accoppiata.

Come si ottiene l'integrità e l'autenticità delle informazioni trasmesse? Per risolvere questo problema, è stato creato un altro meccanismo. I dati aperti non sono crittografati, ma il risultato dell'applicazione della funzione hash crittografica - un'immagine “compressa” della sequenza di dati di input - viene trasmesso in forma crittografata. Il risultato di tale hashing è chiamato "digest" ed è crittografato utilizzando la chiave segreta dell'abbonato mittente ("il testimone"). Come risultato della crittografia del digest, si ottiene una firma digitale. Esso, insieme al testo in chiaro, viene trasmesso all'abbonato destinatario (“verificatore”). Decifra la firma digitale sulla chiave pubblica del testimone e la confronta con il risultato dell’applicazione di una funzione di hash crittografico, che il verificatore calcola autonomamente sulla base degli open data ricevuti. Se corrispondono, ciò indica che i dati sono stati trasmessi in forma autentica e completa dall'abbonato mittente e non modificati da un utente malintenzionato.

La maggior parte delle risorse che lavorano con dati personali e informazioni di pagamento (banche, compagnie assicurative, compagnie aeree, sistemi di pagamento, nonché portali governativi come il servizio fiscale) utilizzano attivamente metodi di crittografia asimmetrica.

Cosa c’entra un certificato digitale? È semplice. Sia il primo che il secondo processo coinvolgono chiavi pubbliche e, poiché rivestono un ruolo centrale, è molto importante assicurarsi che le chiavi appartengano effettivamente al mittente (il testimone, in caso di verifica della firma) o al destinatario, e non siano sostituite con le chiavi degli aggressori. Questo è il motivo per cui esistono certificati digitali per garantire l'autenticità e l'integrità della chiave pubblica.

Nota: l'autenticità e l'integrità della chiave pubblica vengono confermate esattamente allo stesso modo dell'autenticità e dell'integrità dei dati pubblici, ovvero utilizzando una firma digitale elettronica (EDS).
Da dove provengono i certificati digitali?Le autorità di certificazione attendibili, o autorità di certificazione (CA), sono responsabili dell'emissione e del mantenimento dei certificati digitali. Il richiedente richiede l'emissione di un certificato alla CA, si sottopone all'identificazione presso il Centro di Registrazione (CR) e riceve un certificato dalla CA. La CA garantisce che la chiave pubblica del certificato appartiene esattamente all'entità per la quale è stata emessa.

Se non si conferma l'autenticità della chiave pubblica, un utente malintenzionato durante il trasferimento/archiviazione di questa chiave può sostituirla con la propria. Se la sostituzione è avvenuta, l'attaccante potrà decriptare tutto ciò che l'abbonato mittente trasmette all'abbonato ricevente, oppure modificare a propria discrezione gli open data.

I certificati digitali vengono utilizzati ovunque sia disponibile la crittografia asimmetrica. Uno dei certificati digitali più comuni sono i certificati SSL per la comunicazione sicura tramite il protocollo HTTPS. Centinaia di aziende registrate in varie giurisdizioni sono coinvolte nell'emissione di certificati SSL. La quota principale ricade su da cinque a dieci grandi centri di fiducia: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA e CR sono componenti della PKI, che include anche:

• Apri la rubrica – un database pubblico che fornisce l'archiviazione sicura dei certificati digitali.
• Elenco dei certificati revocati – un database pubblico che fornisce l'archiviazione sicura di certificati digitali di chiavi pubbliche revocate (ad esempio, a causa della compromissione di una chiave privata accoppiata). I soggetti dell'infrastruttura possono accedere autonomamente a questo database oppure utilizzare lo specializzato Online Certification Status Protocol (OCSP), che semplifica il processo di verifica.
• Utenti certificati – soggetti PKI serviti che hanno stipulato un contratto d'uso con la CA e verificano la firma digitale e/o crittografano i dati in base alla chiave pubblica del certificato.
• seguito – soggetti PKI serviti che possiedono una chiave segreta abbinata alla chiave pubblica del certificato e che hanno stipulato un contratto di abbonamento con la CA. L'abbonato può essere contemporaneamente un utente del certificato.

Pertanto, le entità attendibili dell'infrastruttura a chiave pubblica, che includono CA, CR e directory aperte, sono responsabili di:

1. Verifica dell'autenticità dell'identità del richiedente.
2. Profilazione del certificato a chiave pubblica.
3. Emissione di un certificato a chiave pubblica per un richiedente la cui identità è stata confermata in modo affidabile.
4. Modificare lo stato del certificato di chiave pubblica.
5. Fornire informazioni sullo stato attuale del certificato a chiave pubblica.

Svantaggi della PKI, quali sono?Il difetto fondamentale della PKI è la presenza di entità fidate.
Gli utenti devono fidarsi incondizionatamente della CA e della CR. Ma, come dimostra la pratica, la fiducia incondizionata è irta di gravi conseguenze.

Negli ultimi dieci anni in questo settore si sono verificati diversi grandi scandali legati alla vulnerabilità delle infrastrutture.

— nel 2010, il malware Stuxnet ha iniziato a diffondersi online, firmato utilizzando certificati digitali rubati a RealTek e JMicron.

- Nel 2017 Google ha accusato Symantec di aver emesso un gran numero di certificati falsificati. A quel tempo, Symantec era una delle più grandi CA in termini di volumi di produzione. Nel browser Google Chrome 70, il supporto per i certificati emessi da questa azienda e dai suoi centri affiliati GeoTrust e Thawte è stato interrotto prima del 1° dicembre 2017.

Le CA sono state compromesse e, di conseguenza, tutti hanno sofferto: le stesse CA, così come gli utenti e gli abbonati. La fiducia nelle infrastrutture è stata minata. Inoltre, i certificati digitali potrebbero essere bloccati nel contesto di conflitti politici, che influenzeranno anche il funzionamento di molte risorse. Questo è esattamente ciò che si temeva diversi anni fa nell’amministrazione presidenziale russa, dove nel 2016 si discuteva della possibilità di creare un centro di certificazione statale che avrebbe rilasciato certificati SSL ai siti della RuNet. Lo stato attuale delle cose è tale che anche i portali statali in Russia usato certificati digitali emessi dalle società americane Comodo o Thawte (una filiale di Symantec).

C'è un altro problema: la domanda autenticazione primaria (autenticazione) degli utenti. Come identificare un utente che ha contattato la CA con la richiesta di emissione di un certificato digitale senza contatto personale diretto? Ora questo viene risolto situazionalmente a seconda delle capacità dell'infrastruttura. Qualcosa viene prelevato dai registri aperti (ad esempio, informazioni sulle persone giuridiche che richiedono certificati); nei casi in cui i richiedenti sono persone fisiche, possono essere utilizzati uffici bancari o uffici postali, dove la loro identità è confermata tramite documenti di identificazione, ad esempio un passaporto.

Il problema della falsificazione delle credenziali a scopo di impersonificazione è fondamentale. Notiamo che non esiste una soluzione completa a questo problema per ragioni di teoria dell'informazione: senza avere informazioni affidabili a priori, è impossibile confermare o negare l'autenticità di un particolare argomento. Di norma, per la verifica è necessario presentare una serie di documenti comprovanti l'identità del richiedente. Esistono molti metodi di verifica diversi, ma nessuno di essi fornisce una garanzia completa dell'autenticità dei documenti. Pertanto, anche l’autenticità dell’identità del richiedente non può essere garantita.

Come si possono eliminare queste carenze?Se i problemi della PKI nel suo stato attuale possono essere spiegati dalla centralizzazione, allora è logico supporre che la decentralizzazione aiuterebbe a eliminare parzialmente le carenze identificate.

La decentralizzazione non implica la presenza di entità fidate, se create infrastrutture decentralizzate a chiave pubblica (Infrastruttura decentralizzata a chiave pubblica, DPKI), allora non sono necessari né CA né CR. Abbandoniamo il concetto di certificato digitale e utilizziamo un registro distribuito per archiviare informazioni sulle chiavi pubbliche. Nel nostro caso chiamiamo registro un database lineare costituito da singoli record (blocchi) collegati tramite la tecnologia blockchain. Al posto del certificato digitale introdurremo il concetto di “notifica”.

Come apparirà il processo di ricezione, verifica e cancellazione delle notifiche nel DPKI proposto:

1. Ogni richiedente presenta una richiesta di notifica in modo indipendente compilando un modulo durante la registrazione, dopodiché crea una transazione che viene archiviata in un pool specializzato.

2. Le informazioni sulla chiave pubblica, insieme ai dettagli del proprietario e altri metadati, sono archiviate in un registro distribuito e non in un certificato digitale, della cui emissione in una PKI centralizzata è responsabile la CA.

3. La verifica dell'autenticità dell'identità del richiedente viene effettuata a posteriori dagli sforzi congiunti della comunità degli utenti DPKI e non dalla CR.

4. Solo il proprietario di tale notifica può modificare lo stato di una chiave pubblica.

5. Chiunque può accedere al registro distribuito e verificare lo stato attuale della chiave pubblica.

Nota: a prima vista la verifica comunitaria dell'identità di un richiedente può sembrare inaffidabile. Ma dobbiamo ricordare che oggigiorno tutti gli utenti dei servizi digitali lasciano inevitabilmente un’impronta digitale, e questo processo continuerà solo ad acquisire slancio. Registri elettronici aperti di persone giuridiche, mappe, digitalizzazione di immagini del terreno, social network: tutti questi sono strumenti disponibili al pubblico. Sono già utilizzati con successo durante le indagini sia da giornalisti che da forze dell'ordine. Basti ricordare, ad esempio, le indagini di Bellingcat o della squadra investigativa congiunta JIT, che sta studiando le circostanze dello schianto del Boeing malese.

Quindi, come funzionerebbe nella pratica un’infrastruttura decentralizzata a chiave pubblica? Soffermiamoci sulla descrizione della tecnologia stessa, che noi brevettato nel 2018 e lo consideriamo giustamente il nostro know-how.

Immagina che ci sia un proprietario che possiede molte chiavi pubbliche, dove ciascuna chiave rappresenta una determinata transazione memorizzata nel registro. In assenza di una CA, come si fa a capire che tutte le chiavi appartengono a questo particolare proprietario? Per risolvere questo problema, viene creata una transazione zero, che contiene informazioni sul proprietario e sul suo portafoglio (da cui viene addebitata la commissione per l'inserimento della transazione nel registro). La transazione nulla è una sorta di “ancora” a cui verranno allegate le transazioni successive con dati sulle chiavi pubbliche. Ciascuna di queste transazioni contiene una struttura dati specializzata o, in altre parole, una notifica.

La notifica è un insieme strutturato di dati costituito da campi funzionali e contenente informazioni sulla chiave pubblica del proprietario, la cui persistenza è garantita dalla collocazione in uno dei record associati del registro distribuito.

La prossima domanda logica è: come si forma una transazione zero? La transazione nulla, come quelle successive, è un'aggregazione di sei campi dati. Durante la formazione di una transazione zero, è coinvolta la coppia di chiavi del portafoglio (chiavi pubbliche e segrete accoppiate). Questa coppia di chiavi appare nel momento in cui l'utente registra il proprio portafoglio, dal quale verrà addebitata la commissione per l'immissione in registro di una transazione pari a zero e, successivamente, delle operazioni con notifiche.

Come mostrato nella figura, un digest della chiave pubblica del portafoglio viene generato applicando sequenzialmente le funzioni hash SHA256 e RIPEMD160. Qui RIPEMD160 è responsabile della rappresentazione compatta dei dati, la cui larghezza non supera i 160 bit. Questo è importante perché il registro non è un database economico. La chiave pubblica stessa viene inserita nel quinto campo. Il primo campo contiene i dati che stabiliscono una connessione con la transazione precedente. Per una transazione pari a zero, questo campo non contiene nulla, il che lo distingue dalle transazioni successive. Il secondo campo sono i dati per verificare la connettività delle transazioni. Per brevità chiameremo i dati del primo e del secondo campo rispettivamente “link” e “check”. Il contenuto di questi campi viene generato tramite hashing iterativo, come dimostrato collegando la seconda e la terza transazione nella figura seguente.

I dati dei primi cinque campi sono certificati da una firma elettronica, generata utilizzando la chiave segreta del portafoglio.

Questo è tutto, la transazione nulla viene inviata al pool e dopo aver verificato con successo viene inserita nel registro. Ora puoi “collegare” ad esso le seguenti transazioni. Consideriamo come si formano le transazioni diverse da zero.

La prima cosa che probabilmente ha attirato la tua attenzione è l'abbondanza di coppie di chiavi. Oltre alla già familiare coppia di chiavi del portafoglio, vengono utilizzate coppie di chiavi ordinarie e di servizio.

Una normale chiave pubblica è ciò per cui tutto è iniziato. Questa chiave è coinvolta in varie procedure e processi che si svolgono nel mondo esterno (transazioni bancarie e di altro tipo, flusso di documenti, ecc.). Ad esempio, una chiave segreta di una coppia ordinaria può essere utilizzata per generare firme digitali per vari documenti - ordini di pagamento, ecc., E una chiave pubblica può essere utilizzata per verificare questa firma digitale con la successiva esecuzione di queste istruzioni, a condizione che sia è valido.

La coppia di servizi viene rilasciata al soggetto DPKI registrato. Il nome di questa coppia corrisponde al suo scopo. Si noti che quando si forma/verifica una transazione zero, le chiavi di servizio non vengono utilizzate.

Chiariamo ancora lo scopo delle chiavi:

1. Le chiavi del portafoglio vengono utilizzate per generare/verificare sia una transazione nulla che qualsiasi altra transazione non nulla. La chiave privata di un portafoglio è nota solo al proprietario del portafoglio, che è anche proprietario di molte chiavi pubbliche ordinarie.
2. Una chiave pubblica ordinaria ha uno scopo simile a una chiave pubblica per la quale viene emesso un certificato in una PKI centralizzata.
3. La coppia di chiavi del servizio appartiene a DPKI. La chiave segreta viene rilasciata alle entità registrate e viene utilizzata durante la generazione di firme digitali per le transazioni (ad eccezione delle transazioni zero). Pubblico viene utilizzato per verificare la firma digitale elettronica di una transazione prima che venga inserita nel registro.

Pertanto, ci sono due gruppi di chiavi. Il primo include le chiavi di servizio e le chiavi del portafoglio: hanno senso solo nel contesto del DPKI. Il secondo gruppo comprende le chiavi ordinarie: il loro ambito può variare ed è determinato dalle attività dell'applicazione in cui vengono utilizzate. Allo stesso tempo, DPKI garantisce l’integrità e l’autenticità delle chiavi pubbliche ordinarie.

Nota: la coppia di chiavi del servizio potrebbe essere nota a diverse entità DPKI. Ad esempio, potrebbe essere uguale per tutti. È per questo motivo che quando si genera la firma di ogni transazione diversa da zero vengono utilizzate due chiavi segrete, una delle quali è la chiave del portafoglio - è nota solo al proprietario del portafoglio, che è anche il proprietario di molti normali chiavi pubbliche. Tutte le chiavi hanno il loro significato. Ad esempio, è sempre possibile dimostrare che la transazione è stata inserita nel registro da un soggetto DPKI registrato, poiché la firma è stata generata anche su una chiave dei servizi segreti. E non possono esserci abusi, come gli attacchi DOS, perché il proprietario paga per ogni transazione.

Tutte le transazioni che seguono lo zero uno sono formate in modo simile: la chiave pubblica (non quella del portafoglio, come nel caso della transazione zero, ma quella di una normale coppia di chiavi) viene gestita attraverso due funzioni hash SHA256 e RIPEMD160. Ecco come si formano i dati del terzo campo. Il quarto campo contiene informazioni di accompagnamento (ad esempio, informazioni sullo stato attuale, date di scadenza, timestamp, identificatori dei crittoalgoritmi utilizzati, ecc.). Il quinto campo contiene la chiave pubblica della coppia di chiavi del servizio. Con il suo aiuto la firma digitale verrà poi verificata e quindi replicata. Giustifichiamo la necessità di un simile approccio.

Ricordiamo che una transazione viene inserita in un pool e ivi archiviata finché non viene elaborata. L'archiviazione in un pool comporta un certo rischio: i dati delle transazioni possono essere falsificati. Il titolare certifica i dati della transazione con una firma digitale elettronica. La chiave pubblica per la verifica di tale firma digitale viene indicata esplicitamente in uno dei campi della transazione e successivamente inserita nel registro. Le peculiarità dell'elaborazione delle transazioni sono tali che un utente malintenzionato è in grado di modificare i dati a propria discrezione, quindi verificarli utilizzando la sua chiave segreta e indicare una chiave pubblica accoppiata per verificare la firma digitale nella transazione. Se l’autenticità e l’integrità fossero garantite esclusivamente attraverso la firma digitale, tale falsificazione passerebbe inosservata. Tuttavia, se oltre alla firma digitale esiste un ulteriore meccanismo che garantisce sia l'archiviazione che la persistenza delle informazioni archiviate, allora la falsificazione può essere rilevata. Per fare ciò è sufficiente inserire nel registro la chiave pubblica autentica del proprietario. Spieghiamo come funziona.

Lascia che l'aggressore falsifichi i dati delle transazioni. Dal punto di vista delle chiavi e delle firme digitali sono possibili le seguenti opzioni:

1. L’aggressore inserisce la sua chiave pubblica nella transazione mentre la firma digitale del proprietario rimane invariata.
2. L’attaccante crea una firma digitale sulla sua chiave privata, ma lascia invariata la chiave pubblica del proprietario.
3. L'aggressore crea una firma digitale sulla sua chiave privata e inserisce una chiave pubblica accoppiata nella transazione.

Ovviamente le opzioni 1 e 2 non hanno senso, poiché verranno sempre rilevate durante la verifica della firma digitale. Solo l’opzione 3 ha senso e se un utente malintenzionato forma una firma digitale sulla propria chiave segreta, è costretto a salvare nella transazione una chiave pubblica accoppiata, diversa dalla chiave pubblica del proprietario. Questo è l'unico modo in cui un utente malintenzionato può imporre dati falsificati.

Supponiamo che il proprietario abbia una coppia fissa di chiavi: privata e pubblica. Lascia che i dati siano certificati mediante firma digitale utilizzando la chiave segreta di questa coppia e la chiave pubblica sia indicata nella transazione. Supponiamo anche che questa chiave pubblica sia stata precedentemente inserita nel registro e che la sua autenticità sia stata verificata in modo affidabile. Quindi una falsificazione sarà indicata dal fatto che la chiave pubblica della transazione non corrisponde alla chiave pubblica del registro.

Riassumiamo. Quando si elaborano i primi dati della transazione del proprietario, è necessario verificare l'autenticità della chiave pubblica inserita nel registro. Per fare ciò, leggere la chiave dal registro e confrontarla con la vera chiave pubblica del proprietario all'interno del perimetro di sicurezza (area di relativa invulnerabilità). Se l'autenticità della chiave è confermata e la sua persistenza è garantita al momento del posizionamento, l'autenticità della chiave della transazione successiva può essere facilmente confermata/smentita confrontandola con la chiave del registro. In altre parole, la chiave del registro viene utilizzata come campione di riferimento. Tutte le altre transazioni del proprietario vengono elaborate in modo simile.

La transazione è certificata da una firma digitale elettronica: è qui che sono necessarie le chiavi segrete, e non una, ma due contemporaneamente: una chiave di servizio e una chiave di portafoglio. Grazie all'utilizzo di due chiavi segrete viene garantito il necessario livello di sicurezza: infatti la chiave segreta del servizio può essere conosciuta anche da altri utenti, mentre la chiave segreta del portafoglio è nota solo al proprietario della normale coppia di chiavi. Abbiamo chiamato questa firma a due chiavi una firma digitale “consolidata”.

La verifica delle transazioni non nulle viene eseguita utilizzando due chiavi pubbliche: il portafoglio e la chiave di servizio. Il processo di verifica può essere suddiviso in due fasi principali: la prima verifica del digest della chiave pubblica del portafoglio, la seconda verifica della firma elettronica digitale della transazione, la stessa consolidata che si è formata utilizzando due chiavi segrete ( portafoglio e servizio). Se la validità della firma digitale viene confermata, dopo un'ulteriore verifica la transazione viene inserita nel registro.

Potrebbe sorgere una domanda logica: come verificare se una transazione appartiene a una catena specifica con la “radice” sotto forma di transazione zero? A questo scopo il processo di verifica viene integrato con un'ulteriore fase: il controllo della connettività. È qui che avremo bisogno dei dati dei primi due campi, che finora abbiamo ignorato.

Immaginiamo di dover verificare se la transazione n. 3 viene effettivamente dopo la transazione n. 2. A tale scopo, utilizzando il metodo di hashing combinato, viene calcolato il valore della funzione hash per i dati del terzo, quarto e quinto campo della transazione n. 2. Quindi vengono eseguiti la concatenazione dei dati dal primo campo della transazione n. 3 e il valore della funzione hash combinato precedentemente ottenuto per i dati dal terzo, quarto e quinto campo della transazione n. 2. Tutto questo viene gestito anche attraverso due funzioni hash SHA256 e RIPEMD160. Se il valore ricevuto corrisponde ai dati nel secondo campo della transazione n. 2, il controllo viene superato e la connessione viene confermata. Ciò è mostrato più chiaramente nelle figure seguenti.

In termini generali, la tecnologia per generare e inserire una notifica nel registro è esattamente così. Un'illustrazione visiva del processo di formazione di una catena di notifiche è presentata nella figura seguente:

In questo testo non ci soffermeremo sui dettagli, che indubbiamente esistono, e torneremo a discutere l’idea stessa di un’infrastruttura a chiave pubblica decentralizzata.

Pertanto, poiché il richiedente stesso presenta una domanda di registrazione delle notifiche, che sono archiviate non nel database della CA, ma nel registro, dovrebbero essere considerati i principali componenti dell'architettura del DPKI:

1. Registro delle notifiche valide (RDN).
2. Registro delle notifiche revocate (RON).
3. Registro delle notifiche sospese (RPN).

Le informazioni sulle chiavi pubbliche vengono archiviate in RDN/RON/RPN sotto forma di valori della funzione hash. È inoltre opportuno notare che si può trattare sia di registri diversi, sia di catene diverse, o addirittura di un'unica catena facente parte di un unico registro, quando nel database vengono inserite informazioni sullo stato di una chiave pubblica ordinaria (revoca, sospensione, ecc.). quarto campo della struttura dati sotto forma del valore del codice corrispondente. Esistono molte opzioni diverse per l'implementazione architetturale di DPKI e la scelta dell'una o dell'altra dipende da una serie di fattori, ad esempio criteri di ottimizzazione come il costo della memoria a lungo termine per l'archiviazione delle chiavi pubbliche, ecc.

Pertanto, DPKI potrebbe rivelarsi, se non più semplice, almeno paragonabile a una soluzione centralizzata in termini di complessità architetturale.

La domanda principale rimane: Quale registro è adatto per implementare la tecnologia?

Il requisito principale per il registro è la capacità di generare transazioni di qualsiasi tipo. L’esempio più famoso di registro è la rete Bitcoin. Ma quando si implementa la tecnologia sopra descritta, sorgono alcune difficoltà: i limiti del linguaggio di scripting esistente, la mancanza di meccanismi necessari per l'elaborazione di insiemi di dati arbitrari, metodi per generare transazioni di tipo arbitrario e molto altro.

Noi di ENCRY abbiamo cercato di risolvere i problemi sopra formulati e abbiamo sviluppato un registro che, a nostro avviso, presenta numerosi vantaggi, vale a dire:

• supporta diversi tipi di transazioni: può sia scambiare beni (cioè eseguire transazioni finanziarie) sia creare transazioni con una struttura arbitraria,
• gli sviluppatori hanno accesso al linguaggio di programmazione proprietario PrismLang, che fornisce la flessibilità necessaria nella risoluzione di vari problemi tecnologici,
• viene fornito un meccanismo per l'elaborazione di set di dati arbitrari.

Se adottiamo un approccio semplificato, avviene la seguente sequenza di azioni:

1. Il richiedente si registra presso DPKI e riceve un portafoglio digitale. L'indirizzo del portafoglio è il valore hash della chiave pubblica del portafoglio. La chiave privata del portafoglio è nota solo al richiedente.
2. Al soggetto registrato viene concesso l'accesso alla chiave segreta del servizio.
3. Il soggetto genera una transazione zero e la verifica con una firma digitale utilizzando la chiave segreta del portafoglio.
4. Se si forma una transazione diversa da zero, questa viene certificata da una firma digitale elettronica che utilizza due chiavi segrete: una di portafoglio e una di servizio.
5. Il soggetto invia una transazione al pool.
6. Il nodo di rete ENCRY legge la transazione dal pool e controlla la firma digitale, nonché la connettività della transazione.
7. Se la firma digitale è valida e la connessione viene confermata, allora prepara la transazione per l'iscrizione nel registro.

In questo caso il registro funge da database distribuito che memorizza informazioni sulle notifiche valide, annullate e sospese.

Naturalmente la decentralizzazione non è una panacea. Il problema fondamentale dell'autenticazione dell'utente primario non scompare da nessuna parte: se attualmente la verifica del richiedente viene effettuata dal CR, allora nel DPKI si propone di delegare la verifica ai membri della comunità e di utilizzare la motivazione finanziaria per stimolare l'attività. La tecnologia di verifica open source è ben nota. L'efficacia di tale verifica è stata confermata nella pratica. Ricordiamo ancora una volta una serie di indagini di alto profilo della pubblicazione online Bellingcat.

Ma in generale emerge il seguente quadro: la DPKI è un’opportunità per correggere, se non tutte, molte delle carenze della PKI centralizzata.

Iscriviti al nostro Habrablog, prevediamo di continuare a coprire attivamente la nostra ricerca e sviluppo e seguire Twitter, se non vuoi perderti altre novità sui progetti ENCRY.

Fonte: habr.com