DPKI: eliminando as deficiencias da PKI centralizada mediante blockchain

Non é ningún segredo que unha das ferramentas auxiliares de uso habitual, sen a cal é imposible a protección de datos en redes abertas, é a tecnoloxía de certificado dixital. Non obstante, non é ningún segredo que o principal inconveniente da tecnoloxía é a confianza incondicional nos centros que emiten certificados dixitais. O director de Tecnoloxía e Innovación de ENCRY, Andrey Chmora, propuxo un novo enfoque de organización infraestrutura de clave pública (Infraestrutura de chave pública, PKI), que axudará a eliminar as deficiencias actuais e que utiliza tecnoloxía de rexistro distribuído (blockchain). Pero primeiro o primeiro.

Se estás familiarizado co funcionamento da túa infraestrutura de chave pública actual e coñeces as súas deficiencias principais, podes pasarte ao que propoñemos cambiar a continuación.

Que son as sinaturas e os certificados dixitais?A interacción en Internet implica sempre a transferencia de datos. Todos temos interese en garantir que os datos se transmitan de forma segura. Pero que é a seguridade? Os servizos de seguridade máis demandados son a confidencialidade, a integridade e a autenticidade. Para este fin, utilízanse actualmente métodos de criptografía asimétrica, ou criptografía con clave pública.

Comecemos co feito de que para usar estes métodos, os suxeitos de interacción deben ter dúas claves pareadas individuais: pública e secreta. Coa súa axuda, ofrécense os servizos de seguridade que mencionamos anteriormente.

Como se consegue a confidencialidade da transferencia de información? Antes de enviar datos, o abonado remitente cifra (transforma criptográficamente) os datos abertos mediante a clave pública do destinatario e o destinatario descifra o texto cifrado recibido mediante a clave secreta emparellada.

Como se consegue a integridade e autenticidade da información transmitida? Para solucionar este problema creouse outro mecanismo. Os datos abertos non están cifrados, pero o resultado da aplicación da función hash criptográfica - unha imaxe "comprimida" da secuencia de datos de entrada - transmítese en forma cifrada. O resultado deste tipo de hash chámase "resumo" e cífrase mediante a clave secreta do subscritor que envía ("a testemuña"). Como resultado do cifrado do resumo, obtense unha sinatura dixital. Este, xunto co texto claro, transmítese ao abonado destinatario ("verificador"). Descifra a sinatura dixital na clave pública da testemuña e compáraa co resultado da aplicación dunha función hash criptográfica, que o verificador calcula de forma independente en función dos datos abertos recibidos. Se coinciden, isto indica que os datos foron transmitidos de forma auténtica e completa polo subscritor remitente e non modificados por un atacante.

A maioría dos recursos que traballan con datos persoais e información de pago (bancos, compañías de seguros, compañías aéreas, sistemas de pago, así como portais gobernamentais como o servizo fiscal) usan activamente métodos de criptografía asimétrica.

Que ten que ver un certificado dixital con iso? É sinxelo. Tanto o primeiro como o segundo procesos implican claves públicas, e dado que desempeñan un papel central, é moi importante asegurarse de que as claves pertencen realmente ao remitente (a testemuña, no caso da verificación da sinatura) ou ao destinatario, e non son substituídas polas claves dos atacantes. É por iso que existen certificados dixitais para garantir a autenticidade e integridade da clave pública.

Nota: a autenticidade e integridade da clave pública confírmase exactamente do mesmo xeito que a autenticidade e integridade dos datos públicos, é dicir, mediante unha sinatura dixital electrónica (EDS).
De onde veñen os certificados dixitais?As autoridades de certificación de confianza, ou as autoridades de certificación (CA), son as responsables de emitir e manter os certificados dixitais. O solicitante solicita a emisión dun certificado da CA, pasa a identificación no Centro de Rexistro (CR) e recibe un certificado da CA. A CA garante que a clave pública do certificado pertence exactamente á entidade para a que foi emitida.

Se non confirma a autenticidade da chave pública, un atacante durante a transferencia/almacenamento desta chave pode substituíla pola súa propia. Se a substitución tivo lugar, o atacante poderá descifrar todo o que o abonado remitente transmita ao abonado receptor, ou cambiar os datos abertos ao seu criterio.

Os certificados dixitais úsanse sempre que exista criptografía asimétrica dispoñible. Un dos certificados dixitais máis comúns son os certificados SSL para a comunicación segura a través do protocolo HTTPS. Centos de empresas rexistradas en varias xurisdicións están implicadas na emisión de certificados SSL. A principal participación recae sobre cinco ou dez grandes centros de confianza: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA e CR son compoñentes de PKI, que tamén inclúe:

• Abrir directorio – unha base de datos pública que proporciona almacenamento seguro de certificados dixitais.
• Lista de revogación de certificados – unha base de datos pública que proporciona un almacenamento seguro de certificados dixitais de claves públicas revogadas (por exemplo, debido á violación dunha clave privada emparellada). Os suxeitos de infraestrutura poden acceder a esta base de datos de forma independente ou poden utilizar o protocolo especializado de estado de certificación en liña (OCSP), que simplifica o proceso de verificación.
• Usuarios certificados – Suxeitos PKI atendidos que celebraron un acordo de usuario coa CA e verifican a sinatura dixital e/ou os datos cifrados baseándose na clave pública do certificado.
• Subscritores – atendeu a suxeitos PKI que posúen unha clave secreta emparellada coa clave pública do certificado e que asinaron un acordo de subscritor coa CA. O abonado pode ser simultaneamente usuario do certificado.

Así, as entidades de confianza da infraestrutura de chave pública, que inclúen CA, CR e directorios abertos, son responsables de:

1. Verificación da autenticidade da identidade do solicitante.
2. Perfil do certificado de clave pública.
3. Expedición dun certificado de clave pública para un solicitante cuxa identidade fose confirmada de forma fidedigna.
4. Cambie o estado do certificado de chave pública.
5. Proporcionar información sobre o estado actual do certificado de clave pública.

Desvantaxes da PKI, cales son?O fallo fundamental da PKI é a presenza de entidades de confianza.
Os usuarios deben confiar incondicionalmente en CA e CR. Pero, como mostra a práctica, a confianza incondicional está chea de graves consecuencias.

Durante os últimos dez anos producíronse varios escándalos importantes nesta área relacionados coa vulnerabilidade das infraestruturas.

— en 2010, o malware Stuxnet comezou a estenderse en liña, asinado mediante certificados dixitais roubados de RealTek e JMicron.

- En 2017, Google acusou a Symantec de emitir un gran número de certificados falsificados. Nese momento, Symantec era unha das maiores CA en canto a volumes de produción. No navegador Google Chrome 70, a compatibilidade cos certificados emitidos por esta empresa e os seus centros afiliados GeoTrust e Thawte detívose antes do 1 de decembro de 2017.

As CA víronse comprometidas e, como resultado, todos sufriron: as propias CA, así como os usuarios e subscritores. A confianza nas infraestruturas foi minada. Ademais, os certificados dixitais poden ser bloqueados no contexto de conflitos políticos, o que tamén afectará ao funcionamento de moitos recursos. Isto é precisamente o que se temía hai varios anos na administración presidencial rusa, onde en 2016 discutiron a posibilidade de crear un centro de certificación estatal que emitise certificados SSL aos sitios da RuNet. O estado actual de cousas é tal que ata os portais estatais en Rusia usar certificados dixitais emitidos polas empresas estadounidenses Comodo ou Thawte (filial de Symantec).

Hai outro problema: a pregunta autenticación primaria (autenticación) dos usuarios. Como identificar un usuario que se puxo en contacto coa CA cunha solicitude para emitir un certificado dixital sen contacto persoal directo? Agora isto resólvese situacionalmente dependendo das capacidades da infraestrutura. Algo tómase de rexistros abertos (por exemplo, información sobre persoas xurídicas que solicitan certificados); nos casos en que os solicitantes son persoas físicas, pódense utilizar oficinas bancarias ou correos, onde se confirma a súa identidade mediante documentos de identificación, por exemplo, un pasaporte.

O problema da falsificación de credenciais con fins de suplantación é fundamental. Teñamos en conta que non existe unha solución completa a este problema por razóns teóricas da información: sen ter unha información fiable a priori, é imposible confirmar ou negar a autenticidade dun determinado tema. Como norma xeral, para a súa comprobación é necesario presentar un conxunto de documentos que acrediten a identidade do solicitante. Hai moitos métodos de verificación diferentes, pero ningún deles ofrece unha garantía total da autenticidade dos documentos. En consecuencia, tampouco se pode garantir a autenticidade da identidade do solicitante.

Como se poden eliminar estas carencias?Se os problemas de PKI no seu estado actual poden explicarse pola centralización, entón é lóxico asumir que a descentralización axudaría a eliminar parcialmente as deficiencias identificadas.

A descentralización non implica a presenza de entidades de confianza, se creas infraestrutura de clave pública descentralizada (Infraestrutura de clave pública descentralizada, DPKI), entón non son necesarios nin CA nin CR. Abandonemos o concepto de certificado dixital e usemos un rexistro distribuído para almacenar información sobre as claves públicas. No noso caso, chamamos un rexistro a unha base de datos lineal que consta de rexistros individuais (bloques) ligados mediante a tecnoloxía blockchain. En lugar dun certificado dixital, introduciremos o concepto de "notificación".

Como será o proceso de recepción, verificación e cancelación de notificacións no DPKI proposto:

1. Cada solicitante presenta unha solicitude de notificación de forma independente enchendo un formulario durante o rexistro, despois de que crea unha transacción que se almacena nun grupo especializado.

2. A información sobre a clave pública, xunto cos datos do propietario e outros metadatos, gárdase nun rexistro distribuído, e non nun certificado dixital, de cuxa emisión nunha PKI centralizada é responsable a CA.

3. A verificación da autenticidade da identidade do solicitante realízase a posteriori polo esforzo conxunto da comunidade de usuarios de DPKI, e non polo CR.

4. Só o propietario desta notificación pode cambiar o estado dunha chave pública.

5. Calquera persoa pode acceder ao libro maior distribuído e comprobar o estado actual da chave pública.

Nota: a verificación comunitaria da identidade dun solicitante pode parecer pouco fiable a primeira vista. Pero hai que lembrar que hoxe en día todos os usuarios de servizos dixitais deixan inevitablemente unha pegada dixital, e este proceso non fará máis que seguir collendo impulso. Rexistros electrónicos abertos de persoas xurídicas, mapas, dixitalización de imaxes do terreo, redes sociais, todo isto son ferramentas dispoñibles para o público. Xa se utilizan con éxito durante as investigacións tanto de xornalistas como de axencias policiais. Por exemplo, abonda con lembrar as investigacións de Bellingcat ou do equipo conxunto de investigación JIT, que estuda as circunstancias do accidente do Boeing malasio.

Entón, como funcionaría na práctica unha infraestrutura de clave pública descentralizada? Detémonos na descrición da propia tecnoloxía, que nós patentado en 2018 e considerámolo con razón o noso saber facer.

Imaxina que hai algún propietario que posúe moitas claves públicas, onde cada clave é unha determinada transacción que se almacena no rexistro. En ausencia dunha CA, como podes entender que todas as chaves pertencen a este propietario en particular? Para resolver este problema, créase unha transacción cero, que contén información sobre o propietario e a súa carteira (da que se carga a comisión por colocar a transacción no rexistro). A transacción nula é unha especie de "áncora" á que se unirán as seguintes transaccións con datos sobre chaves públicas. Cada transacción deste tipo contén unha estrutura de datos especializada, ou noutras palabras, unha notificación.

A notificación é un conxunto estruturado de datos formado por campos funcionais e que inclúe información sobre a chave pública do propietario, cuxa persistencia está garantida pola colocación nun dos rexistros asociados do rexistro distribuído.

A seguinte pregunta lóxica é como se forma unha transacción cero? A transacción nula, como as posteriores, é unha agregación de seis campos de datos. Durante a formación dunha transacción cero, intervén o par de claves da carteira (chaves secretas públicas e emparelladas). Este par de claves aparece no momento no que o usuario rexistra a súa carteira, desde o que se cargará a comisión por colocar unha transacción cero no rexistro e, posteriormente, as operacións con notificacións.

Como se mostra na figura, xérase un resumo de claves públicas de carteira aplicando secuencialmente as funcións hash SHA256 e RIPEMD160. Aquí RIPEMD160 é o responsable da representación compacta dos datos, cuxo ancho non supera os 160 bits. Isto é importante porque o rexistro non é unha base de datos barata. A chave pública en si introdúcese no quinto campo. O primeiro campo contén datos que establecen unha conexión coa transacción anterior. Para unha transacción cero, este campo non contén nada, o que o distingue das transaccións posteriores. O segundo campo son os datos para comprobar a conectividade das transaccións. Para brevidade, chamaremos aos datos do primeiro e segundo campos "ligazón" e "comprobar", respectivamente. Os contidos destes campos xéranse mediante hash iterativo, como se demostra ao ligar a segunda e a terceira transaccións na seguinte figura.

Os datos dos cinco primeiros campos están certificados mediante unha sinatura electrónica, que se xera mediante a clave secreta da carteira.

Isto é todo, a transacción nula envíase ao grupo e despois da verificación exitosa introdúcese no rexistro. Agora podes "enlazar" as seguintes transaccións. Consideremos como se forman as transaccións distintas de cero.

O primeiro que probablemente chamou a atención é a abundancia de pares de chaves. Ademais do xa familiar par de claves de carteira, utilízanse pares de claves comúns e de servizo.

Unha chave pública común é para o que comezou todo. Esta chave está implicada en diversos procedementos e procesos que se desenvolven no exterior (transaccións bancarias e outras, fluxo documental, etc.). Por exemplo, unha chave secreta dun par común pódese utilizar para xerar sinaturas dixitais para varios documentos - ordes de pago, etc., e unha clave pública pode utilizarse para verificar esta sinatura dixital coa execución posterior destas instrucións, sempre que é válido.

O par de servizos emítese ao suxeito DPKI rexistrado. O nome desta parella corresponde á súa finalidade. Teña en conta que ao formar/verificar unha transacción cero, non se usan as claves de servizo.

Volvemos aclarar o propósito das teclas:

1. As claves de carteira úsanse para xerar/verificar tanto unha transacción nula como calquera outra transacción non nula. A clave privada dunha carteira só é coñecida polo propietario da carteira, que tamén é o propietario de moitas claves públicas comúns.
2. Unha clave pública ordinaria ten un propósito similar a unha clave pública para a que se emite un certificado nunha PKI centralizada.
3. O par de chaves de servizo pertence a DPKI. A clave secreta emítese ás entidades rexistradas e utilízase cando se xeran sinaturas dixitais para transaccións (excepto para transaccións cero). Público utilízase para verificar a sinatura dixital electrónica dunha transacción antes de que se publique no rexistro.

Así, hai dous grupos de claves. O primeiro inclúe claves de servizo e de carteira; só teñen sentido no contexto de DPKI. O segundo grupo inclúe claves comúns; o seu alcance pode variar e está determinado polas tarefas da aplicación nas que se usan. Ao mesmo tempo, DPKI garante a integridade e autenticidade das claves públicas comúns.

Nota: O par de claves de servizo pode ser coñecido por diferentes entidades DPKI. Por exemplo, pode ser o mesmo para todos. É por este motivo que ao xerar a sinatura de cada transacción distinta de cero, utilízanse dúas claves secretas, unha delas é a clave da carteira; só o coñece o propietario da carteira, que tamén é o propietario de moitas claves comúns. claves públicas. Todas as claves teñen o seu propio significado. Por exemplo, sempre é posible demostrar que a transacción foi introducida no rexistro por un suxeito DPKI rexistrado, xa que a sinatura tamén se xerou nunha clave de servizo secreto. E non pode haber abuso, como ataques DOS, porque o propietario paga por cada transacción.

Todas as transaccións que seguen a cero fórmanse dun xeito similar: a clave pública (non a carteira, como no caso da transacción cero, senón a partir dun par de claves común) execútase a través de dúas funcións hash SHA256 e RIPEMD160. Así se forman os datos do terceiro campo. O cuarto campo contén información complementaria (por exemplo, información sobre o estado actual, datas de caducidade, marca de tempo, identificadores dos cripto-algoritmos utilizados, etc.). O quinto campo contén a chave pública do par de chaves de servizo. Coa súa axuda comprobarase entón a sinatura dixital, polo que se replicará. Xustifiquemos a necesidade de tal enfoque.

Lembre que unha transacción introdúcese nun grupo e gárdase alí ata que se procesa. O almacenamento nun grupo está asociado a un risco determinado: os datos das transaccións poden ser falsificados. O propietario certifica os datos da transacción cunha sinatura dixital electrónica. A clave pública para verificar esta sinatura dixital indícase de forma explícita nun dos campos de transacción e posteriormente introdúcese no rexistro. As peculiaridades do procesamento de transaccións son tales que un atacante pode cambiar os datos á súa propia discreción e despois verificalos mediante a súa clave secreta e indicar unha clave pública emparellada para verificar a sinatura dixital na transacción. Se a autenticidade e a integridade se garanten exclusivamente mediante a sinatura dixital, esa falsificación pasará desapercibida. Non obstante, se, ademais da sinatura dixital, existe un mecanismo adicional que garante tanto o arquivo como a persistencia da información almacenada, pódese detectar a falsidade. Para iso, abonda con introducir a clave pública xenuína do propietario no rexistro. Imos explicar como funciona isto.

Permite que o atacante falsifique os datos das transaccións. Desde o punto de vista das claves e da sinatura dixital, son posibles as seguintes opcións:

1. O atacante coloca a súa clave pública na transacción mentres a sinatura dixital do propietario permanece sen cambios.
2. O atacante crea unha sinatura dixital na súa clave privada, pero deixa a chave pública do propietario sen cambios.
3. O atacante crea unha sinatura dixital na súa clave privada e coloca unha clave pública emparellada na transacción.

Obviamente, as opcións 1 e 2 carecen de sentido, xa que sempre se detectarán durante a verificación da sinatura dixital. Só a opción 3 ten sentido, e se un atacante forma unha sinatura dixital na súa propia chave secreta, entón vese obrigado a gardar unha chave pública emparellada na transacción, diferente da chave pública do propietario. Este é o único xeito de que un atacante impoña datos falsificados.

Supoñamos que o propietario ten un par fixo de chaves: privadas e públicas. Deixa que os datos estean certificados mediante sinatura dixital usando a clave secreta deste par, e a clave pública indícase na transacción. Supoñamos tamén que esta chave pública se introduciu previamente no rexistro e comprobouse de forma fiable a súa autenticidade. A continuación, indicarase unha falsificación polo feito de que a clave pública da transacción non se corresponde coa clave pública do rexistro.

Resume. Ao procesar os datos da primeira transacción do propietario, é necesario verificar a autenticidade da clave pública introducida no rexistro. Para iso, le a clave do rexistro e compáraa coa verdadeira clave pública do propietario dentro do perímetro de seguridade (área de invulnerabilidade relativa). Se se confirma a autenticidade da chave e se garante a súa persistencia tras a súa colocación, a autenticidade da chave da transacción posterior pódese confirmar/refutar facilmente comparándoa coa clave do rexistro. Noutras palabras, a clave do rexistro úsase como mostra de referencia. Todas as demais transaccións do propietario procesan de forma similar.

A transacción está certificada mediante unha sinatura dixital electrónica - aquí é onde se necesitan claves secretas, e non unha, senón dúas á vez - unha clave de servizo e unha clave de carteira. Grazas ao uso de dúas claves secretas, o nivel de seguridade necesario está garantido; despois de todo, a clave secreta do servizo pode ser coñecida por outros usuarios, mentres que a clave secreta da carteira só é coñecida polo propietario do par de claves común. Chamámoslle a esa sinatura de dúas claves unha sinatura dixital "consolidada".

A verificación de transaccións non nulas realízase mediante dúas claves públicas: a carteira e a clave de servizo. O proceso de verificación pódese dividir en dúas fases principais: a primeira é a comprobación do resumo da clave pública da carteira, e a segunda é a comprobación da sinatura dixital electrónica da transacción, a mesma consolidada que se formou mediante dúas claves secretas ( carteira e servizo). Se se confirma a validez da sinatura dixital, despois dunha verificación adicional, a transacción introdúcese no rexistro.

Pode xurdir unha pregunta lóxica: como comprobar se unha transacción pertence a unha cadea específica coa "raíz" en forma de transacción cero? Para este fin, o proceso de verificación complétase cunha etapa máis: a comprobación da conectividade. Aquí é onde necesitaremos os datos dos dous primeiros campos, que ata agora ignoramos.

Imaxinemos que temos que comprobar se a transacción número 3 chega realmente despois da transacción número 2. Para iso, utilizando o método de hash combinado, calcúlase o valor da función hash para os datos dos campos terceiro, cuarto e quinto da transacción número 2. A continuación, realízase a concatenación de datos do primeiro campo da transacción número 3 e do valor de función hash combinado obtido previamente para os datos dos campos terceiro, cuarto e quinto da transacción número 2. Todo isto tamén se executa a través de dúas funcións hash SHA256 e RIPEMD160. Se o valor recibido coincide cos datos do segundo campo da transacción número 2, a comprobación pásase e confírmase a conexión. Isto móstrase máis claramente nas figuras seguintes.

En termos xerais, a tecnoloxía para xerar e introducir unha notificación no rexistro é exactamente así. Na seguinte figura preséntase unha ilustración visual do proceso de formación dunha cadea de notificacións:

Neste texto, non nos deteremos nos detalles, que sen dúbida existen, e volveremos a discutir a idea mesma dunha infraestrutura de clave pública descentralizada.

Polo tanto, dado que o propio solicitante presenta unha solicitude de rexistro de notificacións, que non se almacenan na base de datos da CA, senón no rexistro, deberían considerarse os principais compoñentes arquitectónicos de DPKI:

1. Rexistro de notificacións válidas (RDN).
2. Rexistro de notificacións revogadas (RON).
3. Rexistro de notificacións suspendidas (RPN).

A información sobre as claves públicas almacénase en RDN/RON/RPN en forma de valores de función hash. Tamén cabe sinalar que estes poden ser rexistros diferentes, ou cadeas diferentes, ou mesmo unha cadea como parte dun rexistro único, cando se introduce información sobre o estado dunha clave pública común (revogación, suspensión, etc.) no cuarto campo da estrutura de datos en forma do valor de código correspondente. Existen moitas opcións diferentes para a implementación arquitectónica de DPKI, e a elección dun ou doutro depende dunha serie de factores, por exemplo, criterios de optimización como o custo da memoria a longo prazo para almacenar claves públicas, etc.

Así, DPKI pode resultar, se non máis sinxelo, polo menos comparable a unha solución centralizada en termos de complexidade arquitectónica.

A pregunta principal segue sendo - Que rexistro é axeitado para implementar a tecnoloxía?

O principal requisito para o rexistro é a capacidade de xerar transaccións de calquera tipo. O exemplo máis famoso dun libro maior é a rede Bitcoin. Pero ao implementar a tecnoloxía descrita anteriormente, xorden certas dificultades: as limitacións da linguaxe de script existente, a falta de mecanismos necesarios para procesar conxuntos de datos arbitrarios, métodos para xerar transaccións de tipo arbitrario e moito máis.

En ENCRY intentamos resolver os problemas formulados anteriormente e desenvolvemos un rexistro que, na nosa opinión, ten unha serie de vantaxes, a saber:

• admite varios tipos de transaccións: pode intercambiar activos (é dicir, realizar transaccións financeiras) e crear transaccións cunha estrutura arbitraria,
• os desenvolvedores teñen acceso á linguaxe de programación propietaria PrismLang, que proporciona a flexibilidade necesaria á hora de resolver diversos problemas tecnolóxicos,
• ofrécese un mecanismo para procesar conxuntos de datos arbitrarios.

Se adoptamos un enfoque simplificado, entón ten lugar a seguinte secuencia de accións:

1. O solicitante rexístrase en DPKI e recibe unha carteira dixital. O enderezo da carteira é o valor hash da clave pública da carteira. A clave privada da carteira só é coñecida polo solicitante.
2. O suxeito rexistrado ten acceso á clave secreta do servizo.
3. O suxeito xera unha transacción cero e verifícao cunha sinatura dixital mediante a clave secreta da carteira.
4. Se se forma unha transacción distinta de cero, esta certificase mediante unha sinatura dixital electrónica mediante dúas claves secretas: unha carteira e outra de servizo.
5. O suxeito envía unha transacción ao grupo.
6. O nodo de rede ENCRY le a transacción do grupo e verifica a sinatura dixital, así como a conectividade da transacción.
7. Se a sinatura dixital é válida e a conexión está confirmada, entón prepara a transacción para a súa entrada no rexistro.

Aquí o rexistro actúa como unha base de datos distribuída que almacena información sobre notificacións válidas, canceladas e suspendidas.

Por suposto, a descentralización non é unha panacea. O problema fundamental da autenticación do usuario principal non desaparece en ningures: se actualmente a verificación do solicitante é realizada polo CR, entón en DPKI proponse delegar a verificación nos membros da comunidade e utilizar a motivación financeira para estimular a actividade. A tecnoloxía de verificación de código aberto é ben coñecida. A eficacia desta verificación confirmouse na práctica. Lembremos de novo unha serie de investigacións de alto perfil da publicación en liña Bellingcat.

Pero, en xeral, emerxe a seguinte imaxe: DPKI é unha oportunidade para corrixir, se non todas, moitas das deficiencias da PKI centralizada.

Subscríbete ao noso Habrablog, pensamos seguir cubrindo activamente a nosa investigación e desenvolvemento, e seguir Twitter, se non queres perderte outras novidades sobre proxectos ENCRY.

Fonte: www.habr.com