No és cap secret que una de les eines auxiliars d'ús habitual, sense la qual la protecció de dades en xarxes obertes és impossible, és la tecnologia de certificats digitals. Tanmateix, no és cap secret que el principal inconvenient de la tecnologia és la confiança incondicional en els centres que emeten certificats digitals. El director de Tecnologia i Innovació d'ENCRY, Andrey Chmora, va proposar un nou enfocament d'organització infraestructura de clau pública (Infraestructura de clau pública, PKI), que ajudarà a eliminar les mancances actuals i que utilitza la tecnologia de registre distribuït (blockchain). Però primer és el primer.
Si esteu familiaritzat amb el funcionament de la vostra infraestructura de clau pública actual i coneixeu les seves deficiències clau, podeu passar per endavant al que proposem canviar a continuació.
Què són les signatures i els certificats digitals?La interacció a Internet sempre implica la transferència de dades. Tots tenim interès a garantir que les dades es transmetin de manera segura. Però què és la seguretat? Els serveis de seguretat més sol·licitats són la confidencialitat, la integritat i l'autenticitat. Amb aquesta finalitat, actualment s'utilitzen mètodes de criptografia asimètrica, o criptografia amb clau pública.
Comencem pel fet que per utilitzar aquests mètodes, els subjectes d'interacció han de tenir dues claus individuals aparellades: pública i secreta. Amb la seva ajuda, es proporcionen els serveis de seguretat que hem esmentat anteriorment.
Com s'aconsegueix la confidencialitat de la transferència d'informació? Abans d'enviar dades, l'abonat que envia xifra (transforma criptogràficament) les dades obertes mitjançant la clau pública del destinatari, i el destinatari desxifra el text xifrat rebut mitjançant la clau secreta emparellada.
Com s'aconsegueix la integritat i l'autenticitat de la informació transmesa? Per solucionar aquest problema, es va crear un altre mecanisme. Les dades obertes no es xifren, però el resultat de l'aplicació de la funció hash criptogràfica -una imatge "comprimida" de la seqüència de dades d'entrada- es transmet en forma xifrada. El resultat d'aquest hashing s'anomena "resum" i es xifra mitjançant la clau secreta del subscriptor que l'envia ("el testimoni"). Com a resultat del xifrat del resum, s'obté una signatura digital. Aquest, juntament amb el text clar, es transmet al subscriptor destinatari ("verificador"). Desxifra la signatura digital a la clau pública del testimoni i la compara amb el resultat d'aplicar una funció hash criptogràfica, que el verificador calcula de manera independent a partir de les dades obertes rebudes. Si coincideixen, això indica que les dades van ser transmeses de forma autèntica i completa per l'abonat que l'envia, i no modificades per un atacant.
La majoria dels recursos que treballen amb dades personals i informació de pagament (bancs, companyies d'assegurances, companyies aèries, sistemes de pagament, així com portals governamentals com el servei fiscal) utilitzen activament mètodes de criptografia asimètrica.
Què hi té a veure un certificat digital? És fàcil. Tant el primer com el segon procés impliquen claus públiques, i com que tenen un paper central, és molt important assegurar-se que les claus realment pertanyen a l'emissor (el testimoni, en el cas de la verificació de la signatura) o al destinatari, i no són substituït per les claus dels atacants. És per això que existeixen els certificats digitals per garantir l'autenticitat i la integritat de la clau pública.
Nota: l'autenticitat i integritat de la clau pública es confirma exactament de la mateixa manera que l'autenticitat i la integritat de les dades públiques, és a dir, mitjançant una signatura digital electrònica (EDS).
D'on provenen els certificats digitals?Les autoritats de certificació de confiança, o les autoritats de certificació (CA), són responsables d'emetre i mantenir els certificats digitals. El sol·licitant sol·licita l'expedició d'un certificat a l'AC, se sotmet a la identificació al Centre de Registre (CR) i rep un certificat de l'AC. La CA garanteix que la clau pública del certificat pertany exactament a l'entitat per a la qual s'ha emès.
Si no confirmeu l'autenticitat de la clau pública, un atacant durant la transferència/emmagatzematge d'aquesta clau pot substituir-la per la seva. Si s'ha produït la substitució, l'atacant podrà desxifrar tot allò que l'abonat remitent transmet a l'abonat receptor, o canviar les dades obertes a la seva discreció.
Els certificats digitals s'utilitzen sempre que hi hagi criptografia asimètrica disponible. Un dels certificats digitals més comuns són els certificats SSL per a una comunicació segura mitjançant el protocol HTTPS. Centenars d'empreses registrades a diverses jurisdiccions participen en l'emissió de certificats SSL. La part principal recau entre cinc i deu grans centres de confiança: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA i CR són components de PKI, que també inclou:
- Directori obert – una base de dades pública que proporciona emmagatzematge segur de certificats digitals.
- Llista de revocació de certificats – una base de dades pública que proporciona emmagatzematge segur de certificats digitals de claus públiques revocades (per exemple, a causa del compromís d'una clau privada emparellada). Els subjectes d'infraestructura poden accedir de manera independent a aquesta base de dades, o bé poden utilitzar el protocol especialitzat d'estat de certificació en línia (OCSP), que simplifica el procés de verificació.
- Usuaris de certificat – subjectes de PKI atesos que hagin subscrit un acord d'usuari amb l'AC i verifiquen la signatura digital i/o les dades xifrades a partir de la clau pública del certificat.
- Seguidors – subjectes de PKI atesos que posseeixen una clau secreta emparellada amb la clau pública del certificat i que han subscrit un acord de subscriptor amb la CA. El subscriptor pot ser simultàniament usuari del certificat.
Així, les entitats de confiança de la infraestructura de clau pública, que inclouen CA, CR i directoris oberts, són responsables de:
1. Verificació de l'autenticitat de la identitat del sol·licitant.
2. Perfil del certificat de clau pública.
3. Emissió d'un certificat de clau pública per a un sol·licitant la identitat del qual s'hagi confirmat de manera fiable.
4. Canvieu l'estat del certificat de clau pública.
5. Proporcionar informació sobre l'estat actual del certificat de clau pública.
Desavantatges de la PKI, quins són?El defecte fonamental de PKI és la presència d'entitats de confiança.
Els usuaris han de confiar incondicionalment en CA i CR. Però, com demostra la pràctica, la confiança incondicional està plena de greus conseqüències.
Durant els darrers deu anys, hi ha hagut diversos escàndols importants en aquest àmbit relacionats amb la vulnerabilitat de les infraestructures.
— el 2010, el programari maliciós Stuxnet va començar a estendre's en línia, signat amb certificats digitals robats de RealTek i JMicron.
- El 2017, Google va acusar Symantec d'emetre un gran nombre de certificats falsificats. En aquell moment, Symantec era una de les CA més grans pel que fa a volums de producció. Al navegador Google Chrome 70, la compatibilitat amb els certificats emesos per aquesta empresa i els seus centres afiliats GeoTrust i Thawte es va aturar abans de l'1 de desembre de 2017.
Les CA es van veure compromeses i, com a resultat, tothom va patir: les mateixes CA, així com els usuaris i els subscriptors. S'ha minat la confiança en les infraestructures. A més, els certificats digitals es poden bloquejar en el context de conflictes polítics, fet que també afectarà el funcionament de molts recursos. Això és precisament el que es temia fa uns quants anys a l'administració presidencial russa, on el 2016 van discutir la possibilitat de crear un centre de certificació estatal que emetés certificats SSL als llocs de la RuNet. L'estat actual de les coses és tal que fins i tot els portals estatals a Rússia certificats digitals emesos per les empreses nord-americanes Comodo o Thawte (filial de Symantec).
Hi ha un altre problema: la pregunta autenticació primària (autenticació) dels usuaris. Com identificar un usuari que s'ha posat en contacte amb la CA amb una sol·licitud d'emissió d'un certificat digital sense contacte personal directe? Ara això es resol situacionalment en funció de les capacitats de la infraestructura. Alguna cosa es treu de registres oberts (per exemple, informació sobre persones jurídiques que demanen certificats); en els casos en què els sol·licitants són persones físiques, es poden utilitzar oficines bancàries o oficines de correus, on la seva identitat es confirma mitjançant documents identificatius, per exemple, un passaport.
El problema de la falsificació de credencials amb finalitats de suplantació d'identitat és fonamental. Fixem-nos que no hi ha una solució completa a aquest problema per raons teòriques de la informació: sense disposar d'una informació fiable a priori, és impossible confirmar o negar l'autenticitat d'un determinat tema. Per regla general, per a la comprovació és necessari presentar un conjunt de documents que acreditin la identitat del sol·licitant. Hi ha molts mètodes de verificació diferents, però cap d'ells ofereix una garantia total de l'autenticitat dels documents. En conseqüència, tampoc es pot garantir l'autenticitat de la identitat del sol·licitant.
Com es poden eliminar aquestes mancances?Si els problemes de la PKI en el seu estat actual es poden explicar mitjançant la centralització, és lògic suposar que la descentralització ajudaria a eliminar parcialment les mancances identificades.
La descentralització no implica la presència d'entitats de confiança, si es crea infraestructura de clau pública descentralitzada (Infraestructura de clau pública descentralitzada, DPKI), aleshores no calen ni CA ni CR. Abandonem el concepte de certificat digital i utilitzem un registre distribuït per emmagatzemar informació sobre les claus públiques. En el nostre cas, anomenem un registre una base de dades lineal que consta de registres individuals (blocs) enllaçats mitjançant la tecnologia blockchain. En lloc d'un certificat digital, introduirem el concepte de "notificació".
Com serà el procés de recepció, verificació i cancel·lació de notificacions al DPKI proposat:
1. Cada sol·licitant presenta una sol·licitud de notificació de manera independent omplint un formulari durant el registre, després del qual crea una transacció que s'emmagatzema en un grup especialitzat.
2. La informació sobre la clau pública, juntament amb les dades del propietari i altres metadades, s'emmagatzema en un registre distribuït, i no en un certificat digital, de l'emissió del qual en una PKI centralitzada és responsable l'AC.
3. La verificació de l'autenticitat de la identitat del sol·licitant es realitza posteriorment per l'esforç conjunt de la comunitat d'usuaris de DPKI, i no pel CR.
4. Només el propietari d'aquesta notificació pot canviar l'estat d'una clau pública.
5. Qualsevol persona pot accedir al registre distribuït i comprovar l'estat actual de la clau pública.
Nota: la verificació de la comunitat de la identitat d'un sol·licitant pot semblar poc fiable a primera vista. Però hem de recordar que avui en dia tots els usuaris dels serveis digitals deixen inevitablement una petjada digital, i aquest procés només seguirà agafant embranzida. Registres electrònics oberts de persones jurídiques, mapes, digitalització d'imatges del terreny, xarxes socials, totes aquestes eines disponibles públicament. Ja s'utilitzen amb èxit durant les investigacions tant de periodistes com de les forces de l'ordre. Per exemple, n'hi ha prou de recordar les investigacions de Bellingcat o de l'equip d'investigació conjunt JIT, que estudien les circumstàncies de l'accident del Boeing de Malàisia.
Aleshores, com funcionaria a la pràctica una infraestructura de clau pública descentralitzada? Anem a detenir-nos en la descripció de la pròpia tecnologia, que nosaltres patentat el 2018 i ho considerem amb raó el nostre saber fer.
Imagineu que hi ha algun propietari que posseeix moltes claus públiques, on cada clau és una transacció determinada que s'emmagatzema al registre. En absència d'una CA, com podeu entendre que totes les claus pertanyen a aquest propietari en concret? Per resoldre aquest problema, es crea una transacció zero, que conté informació sobre el propietari i la seva cartera (de la qual es carrega la comissió per col·locar la transacció al registre). La transacció nul·la és una mena d'"àncora" a la qual s'adjuntaran les següents transaccions amb dades sobre claus públiques. Cada transacció conté una estructura de dades especialitzada, o en altres paraules, una notificació.
La notificació és un conjunt estructurat de dades format per camps funcionals i que inclou informació sobre la clau pública del propietari, la persistència de les quals està garantida mitjançant la col·locació en un dels registres associats del registre distribuït.
La següent pregunta lògica és com es forma una transacció zero? La transacció nul·la, com les posteriors, és una agregació de sis camps de dades. Durant la formació d'una transacció zero, intervé el parell de claus de la cartera (claus secretes públiques i aparellades). Aquest parell de claus apareix en el moment en què l'usuari registra la seva cartera, a partir del qual es carregarà la comissió per col·locar una transacció zero al registre i, posteriorment, les operacions amb notificacions.
Com es mostra a la figura, es genera un resum de claus públiques de cartera aplicant seqüencialment les funcions hash SHA256 i RIPEMD160. Aquí RIPEMD160 és responsable de la representació compacta de les dades, l'amplada de les quals no supera els 160 bits. Això és important perquè el registre no és una base de dades barata. La pròpia clau pública s'introdueix al cinquè camp. El primer camp conté dades que estableixen una connexió amb la transacció anterior. Per a una transacció zero, aquest camp no conté res, cosa que el distingeix de les transaccions posteriors. El segon camp són les dades per comprovar la connectivitat de les transaccions. Per a més brevetat, anomenarem les dades del primer i segon camps "enllaç" i "comprovar", respectivament. El contingut d'aquests camps es genera mitjançant hashing iteratiu, tal com es demostra enllaçant la segona i la tercera transacció a la figura següent.
Les dades dels cinc primers camps estan certificades per una signatura electrònica, que es genera mitjançant la clau secreta de la cartera.
Això és tot, la transacció nul·la s'envia al grup i, després de la verificació correcta, s'introdueix al registre. Ara podeu "enllaçar" les següents transaccions. Considerem com es formen les transaccions diferents de zero.
El primer que probablement us va cridar l'atenció és l'abundància de parells de claus. A més del ja conegut parell de claus de la cartera, s'utilitzen parells de claus normals i de servei.
Una clau pública normal és per a què es va començar tot. Aquesta clau està implicada en diferents tràmits i processos que es desenvolupen a l'exterior (operacions bancàries i altres, flux documental, etc.). Per exemple, una clau secreta d'una parella normal es pot utilitzar per generar signatures digitals per a diversos documents - ordres de pagament, etc., i una clau pública es pot utilitzar per verificar aquesta signatura digital amb l'execució posterior d'aquestes instruccions, sempre que és vàlid.
El parell de serveis s'emet al subjecte DPKI registrat. El nom d'aquesta parella correspon a la seva finalitat. Tingueu en compte que en formar/comprovar una transacció zero, no s'utilitzen les claus de servei.
Tornem a aclarir el propòsit de les claus:
- Les claus de cartera s'utilitzen per generar/verificar tant una transacció nul·la com qualsevol altra que no sigui nul·la. La clau privada d'una cartera només la coneix el propietari de la cartera, que també és el propietari de moltes claus públiques ordinàries.
- Una clau pública ordinària té un propòsit similar a una clau pública per a la qual s'emet un certificat en una PKI centralitzada.
- El parell de claus de servei pertany a DPKI. La clau secreta s'emet a les entitats registrades i s'utilitza quan es generen signatures digitals per a transaccions (excepte transaccions zero). Public s'utilitza per verificar la signatura digital electrònica d'una transacció abans de publicar-la al registre.
Així, hi ha dos grups de claus. El primer inclou claus de servei i claus de cartera: només tenen sentit en el context de DPKI. El segon grup inclou claus ordinàries: el seu abast pot variar i està determinat per les tasques de l'aplicació en què s'utilitzen. Al mateix temps, DPKI garanteix la integritat i l'autenticitat de les claus públiques ordinàries.
Nota: El parell de claus de servei pot ser conegut per diferents entitats DPKI. Per exemple, pot ser el mateix per a tothom. És per aquest motiu que en generar la signatura de cada transacció diferent de zero, s'utilitzen dues claus secretes, una de les quals és la clau de la cartera; només la coneix el propietari de la cartera, que també és el propietari de moltes claus normals. claus públiques. Totes les claus tenen el seu propi significat. Per exemple, sempre és possible demostrar que la transacció va ser introduïda al registre per un subjecte DPKI registrat, ja que la signatura també es va generar en una clau del servei secret. I no hi pot haver abús, com ara atacs DOS, perquè el propietari paga per cada transacció.
Totes les transaccions que segueixen el zero es formen de manera similar: la clau pública (no la cartera, com en el cas de la transacció zero, sinó a partir d'un parell de claus normal) s'executa mitjançant dues funcions hash SHA256 i RIPEMD160. Així es formen les dades del tercer camp. El quart camp conté la informació que l'acompanya (per exemple, informació sobre l'estat actual, dates de caducitat, marca de temps, identificadors dels cripto-algorismes utilitzats, etc.). El cinquè camp conté la clau pública del parell de claus de servei. Amb la seva ajuda, després es comprovarà la signatura digital, de manera que es replicarà. Justifiquem la necessitat d'aquest enfocament.
Recordeu que una transacció s'introdueix en un grup i s'hi emmagatzema fins que es processa. L'emmagatzematge en un grup està associat a un cert risc: les dades de transacció es poden falsificar. El propietari certifica les dades de la transacció amb una signatura digital electrònica. La clau pública per a la verificació d'aquesta signatura digital s'indica explícitament en un dels camps de transacció i s'introdueix posteriorment en el registre. Les peculiaritats del processament de transaccions són tals que un atacant és capaç de canviar les dades a la seva discreció i després verificar-les mitjançant la seva clau secreta i indicar una clau pública aparellada per verificar la signatura digital de la transacció. Si l'autenticitat i la integritat es garanteixen exclusivament mitjançant la signatura digital, aquesta falsificació passarà desapercebuda. Tanmateix, si, a més de la signatura digital, hi ha un mecanisme addicional que garanteixi tant l'arxiu com la persistència de la informació emmagatzemada, es pot detectar la falsificació. Per fer-ho, n'hi ha prou amb introduir la clau pública genuïna del propietari al registre. Expliquem com funciona això.
Deixeu que l'atacant forgi dades de transaccions. Des del punt de vista de claus i signatures digitals, són possibles les opcions següents:
1. L'atacant posa la seva clau pública a la transacció mentre la signatura digital del propietari no canvia.
2. L'atacant crea una signatura digital a la seva clau privada, però deixa sense canvis la clau pública del propietari.
3. L'atacant crea una signatura digital a la seva clau privada i col·loca una clau pública aparellada a la transacció.
Evidentment, les opcions 1 i 2 no tenen sentit, ja que sempre es detectaran durant la verificació de la signatura digital. Només l'opció 3 té sentit, i si un atacant forma una signatura digital amb la seva pròpia clau secreta, llavors es veu obligat a desar una clau pública aparellada a la transacció, diferent de la clau pública del propietari. Aquesta és l'única manera que té un atacant d'imposar dades falsificades.
Suposem que el propietari té un parell fix de claus: privades i públiques. Deixeu que les dades es certificin mitjançant signatura digital utilitzant la clau secreta d'aquest parell, i la clau pública s'indica a la transacció. Suposem també que aquesta clau pública s'ha introduït prèviament al registre i la seva autenticitat s'ha verificat de manera fiable. Aleshores, s'indicarà una falsificació pel fet que la clau pública de la transacció no es correspon amb la clau pública del registre.
Resumeix. Quan es processen les dades de la primera transacció del propietari, cal verificar l'autenticitat de la clau pública introduïda al registre. Per fer-ho, llegiu la clau del registre i compareu-la amb la veritable clau pública del propietari dins del perímetre de seguretat (àrea d'invulnerabilitat relativa). Si es confirma l'autenticitat de la clau i es garanteix la seva persistència en la col·locació, llavors l'autenticitat de la clau de la transacció posterior es pot confirmar/refutar fàcilment comparant-la amb la clau del registre. En altres paraules, la clau del registre s'utilitza com a mostra de referència. Totes les altres transaccions del propietari es processen de la mateixa manera.
La transacció està certificada per una signatura digital electrònica - aquí és on es necessiten claus secretes, i no una, sinó dues alhora - una clau de servei i una clau de cartera. Gràcies a l'ús de dues claus secretes, es garanteix el nivell de seguretat necessari; després de tot, la clau secreta del servei pot ser coneguda per altres usuaris, mentre que la clau secreta de la cartera només la coneix el propietari del parell de claus normal. Vam anomenar aquesta signatura de dues claus una signatura digital "consolidada".
La verificació de transaccions no nul·les es realitza mitjançant dues claus públiques: la cartera i la clau de servei. El procés de verificació es pot dividir en dues etapes principals: la primera és la comprovació del resum de la clau pública de la cartera, i la segona és la comprovació de la signatura digital electrònica de la transacció, la mateixa consolidada que es va formar mitjançant dues claus secretes ( cartera i servei). Si es confirma la validesa de la signatura digital, després d'una verificació addicional, la transacció s'inscriu al registre.
Pot sorgir una pregunta lògica: com comprovar si una transacció pertany a una cadena específica amb l'"arrel" en forma de transacció zero? Amb aquesta finalitat, el procés de verificació es complementa amb una etapa més: la comprovació de la connectivitat. Aquí és on necessitarem les dades dels dos primers camps, que fins ara hem ignorat.
Imaginem que hem de comprovar si la transacció número 3 arriba realment després de la transacció número 2. Per fer-ho, mitjançant el mètode hash combinat, es calcula el valor de la funció hash per a les dades dels camps tercer, quart i cinquè de la transacció número 2. A continuació, es realitza la concatenació de dades del primer camp de la transacció núm. 3 i el valor de funció hash combinat obtingut prèviament per a les dades del tercer, quart i cinquè camps de la transacció núm. 2. Tot això també s'executa mitjançant dues funcions hash SHA256 i RIPEMD160. Si el valor rebut coincideix amb les dades del segon camp de la transacció núm. 2, es passa la comprovació i es confirma la connexió. Això es mostra més clarament a les figures següents.
En termes generals, la tecnologia per generar i introduir una notificació al registre és exactament així. A la figura següent es presenta una il·lustració visual del procés de formació d'una cadena de notificacions:
En aquest text, no ens detenem en els detalls, que sens dubte existeixen, i tornarem a parlar de la idea mateixa d'una infraestructura de clau pública descentralitzada.
Així, com que el sol·licitant mateix presenta una sol·licitud de registre de notificacions, que no s'emmagatzemen a la base de dades CA, sinó al registre, s'han de tenir en compte els principals components arquitectònics de DPKI:
1. Registre de notificacions vàlides (RDN).
2. Registre de notificacions revocades (RON).
3. Registre de notificacions suspeses (RPN).
La informació sobre les claus públiques s'emmagatzema a RDN/RON/RPN en forma de valors de funció hash. També val la pena assenyalar que poden ser registres diferents, o cadenes diferents, o fins i tot una cadena com a part d'un únic registre, quan s'introdueix informació sobre l'estat d'una clau pública ordinària (revocació, suspensió, etc.) al quart camp de l'estructura de dades en forma del valor de codi corresponent. Hi ha moltes opcions diferents per a la implementació arquitectònica de DPKI, i l'elecció d'una o altra depèn d'una sèrie de factors, per exemple, criteris d'optimització com el cost de la memòria a llarg termini per emmagatzemar claus públiques, etc.
Així, DPKI pot resultar, si no més senzill, com a mínim comparable a una solució centralitzada en termes de complexitat arquitectònica.
La pregunta principal segueix sent - Quin registre és adequat per implementar la tecnologia?
El principal requisit per al registre és la capacitat de generar transaccions de qualsevol tipus. L'exemple més famós d'un llibre major és la xarxa Bitcoin. Però en implementar la tecnologia descrita anteriorment, sorgeixen certes dificultats: les limitacions del llenguatge de script existent, la manca de mecanismes necessaris per processar conjunts arbitraris de dades, mètodes per generar transaccions de tipus arbitrari i molt més.
A ENCRY hem intentat resoldre els problemes anteriors i hem desenvolupat un registre que, segons la nostra opinió, té una sèrie d'avantatges, a saber:
- Admet diversos tipus de transaccions: pot tant intercanviar actius (és a dir, realitzar transaccions financeres) com crear transaccions amb una estructura arbitrària,
- els desenvolupadors tenen accés al llenguatge de programació propietari PrismLang, que proporciona la flexibilitat necessària a l'hora de resoldre diversos problemes tecnològics,
- es proporciona un mecanisme per processar conjunts de dades arbitraris.
Si adoptem un enfocament simplificat, es produeix la següent seqüència d'accions:
- El sol·licitant es registra a DPKI i rep una cartera digital. L'adreça de la cartera és el valor hash de la clau pública de la cartera. La clau privada de la cartera només la coneix el sol·licitant.
- El subjecte registrat té accés a la clau secreta del servei.
- El subjecte genera una transacció zero i la verifica amb una signatura digital mitjançant la clau secreta de la cartera.
- Si es forma una transacció diferent de zero, es certifica mitjançant una signatura digital electrònica mitjançant dues claus secretes: una cartera i una de servei.
- El subjecte envia una transacció al grup.
- El node de xarxa ENCRY llegeix la transacció del grup i comprova la signatura digital, així com la connectivitat de la transacció.
- Si la signatura digital és vàlida i la connexió es confirma, prepara la transacció per a la seva entrada al registre.
Aquí el registre actua com una base de dades distribuïda que emmagatzema informació sobre notificacions vàlides, cancel·lades i suspeses.
Per descomptat, la descentralització no és una panacea. El problema fonamental de l'autenticació de l'usuari principal no desapareix enlloc: si actualment la verificació del sol·licitant la porta a terme el CR, aleshores a DPKI es proposa delegar la verificació als membres de la comunitat i utilitzar la motivació financera per estimular l'activitat. La tecnologia de verificació de codi obert és ben coneguda. L'eficàcia d'aquesta verificació s'ha confirmat a la pràctica. Recordem de nou una sèrie d'investigacions d'alt perfil de la publicació en línia Bellingcat.
Però, en general, sorgeix la següent imatge: DPKI és una oportunitat per corregir, si no totes, moltes de les mancances de la PKI centralitzada.
Subscriu-te al nostre Habrablog, tenim previst continuar cobrint activament la nostra recerca i desenvolupament i seguir-lo , si no us voleu perdre altres notícies sobre projectes ENCRY.
Font: www.habr.com