No es ningún secreto que una de las herramientas auxiliares más utilizadas, sin la cual la protección de datos en redes abiertas es imposible, es la tecnología de certificados digitales. Sin embargo, no es ningún secreto que el principal inconveniente de la tecnología es la confianza incondicional en los centros que emiten los certificados digitales. El director de Tecnología e Innovación de ENCRY, Andrey Chmora, propuso un nuevo enfoque de organización Infraestructura de Clave Pública (Infraestructura de Clave Pública, PKI), que ayudará a eliminar las deficiencias actuales y que utiliza tecnología de contabilidad distribuida (blockchain). Pero primero lo primero.
Si está familiarizado con el funcionamiento de su infraestructura de clave pública actual y conoce sus principales deficiencias, puede pasar a lo que proponemos cambiar a continuación.
¿Qué son las firmas y los certificados digitales?La interacción en Internet siempre implica la transferencia de datos. A todos nos interesa garantizar que los datos se transmitan de forma segura. Pero ¿qué es la seguridad? Los servicios de seguridad más buscados son la confidencialidad, la integridad y la autenticidad. Para ello, actualmente se utilizan métodos de criptografía asimétrica, o criptografía con clave pública.
Comencemos con el hecho de que para utilizar estos métodos, los sujetos de interacción deben tener dos claves individuales emparejadas: pública y secreta. Con su ayuda, se brindan los servicios de seguridad que mencionamos anteriormente.
¿Cómo se logra la confidencialidad de la transferencia de información? Antes de enviar datos, el suscriptor emisor cifra (transforma criptográficamente) los datos abiertos utilizando la clave pública del destinatario, y el destinatario descifra el texto cifrado recibido utilizando la clave secreta emparejada.
¿Cómo se logra la integridad y autenticidad de la información transmitida? Para solucionar este problema, se creó otro mecanismo. Los datos abiertos no están cifrados, pero el resultado de aplicar la función hash criptográfica (una imagen "comprimida" de la secuencia de datos de entrada) se transmite en forma cifrada. El resultado de dicho hash se denomina "resumen" y se cifra utilizando la clave secreta del suscriptor emisor ("el testigo"). Como resultado del cifrado del resumen, se obtiene una firma digital. Este, junto con el texto claro, se transmite al suscriptor destinatario ("verificador"). Descifra la firma digital en la clave pública del testigo y la compara con el resultado de aplicar una función hash criptográfica, que el verificador calcula de forma independiente basándose en los datos abiertos recibidos. Si coinciden, esto indica que los datos fueron transmitidos de forma auténtica y completa por el suscriptor emisor, y no modificados por un atacante.
La mayoría de los recursos que trabajan con datos personales e información de pago (bancos, compañías de seguros, aerolíneas, sistemas de pago, así como portales gubernamentales como el servicio de impuestos) utilizan activamente métodos de criptografía asimétrica.
¿Qué tiene que ver un certificado digital con esto? Es sencillo. Tanto el primer como el segundo proceso implican claves públicas y, dado que desempeñan un papel central, es muy importante garantizar que las claves realmente pertenezcan al remitente (el testigo, en el caso de la verificación de firmas) o al destinatario, y no sean reemplazado con las llaves de los atacantes. Por eso existen los certificados digitales para garantizar la autenticidad e integridad de la clave pública.
Nota: la autenticidad e integridad de la clave pública se confirma exactamente de la misma manera que la autenticidad e integridad de los datos públicos, es decir, mediante una firma digital electrónica (EDS).
¿De dónde proceden los certificados digitales?Las autoridades de certificación confiables, o autoridades de certificación (CA), son responsables de emitir y mantener los certificados digitales. El solicitante solicita la emisión de un certificado de la CA, se identifica en el Centro de Registro (CR) y recibe un certificado de la CA. La CA garantiza que la clave pública del certificado pertenece exactamente a la entidad para la que fue emitida.
Si no confirma la autenticidad de la clave pública, entonces un atacante durante la transferencia/almacenamiento de esta clave puede reemplazarla por la suya propia. Si se ha producido la sustitución, el atacante podrá descifrar todo lo que el suscriptor emisor transmite al suscriptor receptor o cambiar los datos abiertos a su propia discreción.
Los certificados digitales se utilizan siempre que esté disponible la criptografía asimétrica. Uno de los certificados digitales más comunes son los certificados SSL para una comunicación segura a través del protocolo HTTPS. Cientos de empresas registradas en diversas jurisdicciones participan en la emisión de certificados SSL. La mayor parte recae en cinco o diez grandes centros de confianza: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA y CR son componentes de PKI, que también incluye:
- Directorio abierto – una base de datos pública que proporciona almacenamiento seguro de certificados digitales.
- Lista de certificados revocados – una base de datos pública que proporciona almacenamiento seguro de certificados digitales de claves públicas revocadas (por ejemplo, debido al compromiso de una clave privada emparejada). Los sujetos de la infraestructura pueden acceder de forma independiente a esta base de datos o pueden utilizar el Protocolo de estado de certificación en línea (OCSP) especializado, que simplifica el proceso de verificación.
- Usuarios de certificados – sujetos de PKI atendidos que han celebrado un acuerdo de usuario con la CA y verifican la firma digital y/o cifran los datos basándose en la clave pública del certificado.
- seguidores – atendió a sujetos de PKI que poseen una clave secreta emparejada con la clave pública del certificado y que han celebrado un acuerdo de suscriptor con la CA. El suscriptor puede ser simultáneamente usuario del certificado.
Así, las entidades confiables de la infraestructura de clave pública, que incluyen CA, CR y directorios abiertos, son responsables de:
1. Verificación de la autenticidad de la identidad del solicitante.
2. Perfilado del certificado de clave pública.
3. Emitir un certificado de clave pública para un solicitante cuya identidad haya sido confirmada fehacientemente.
4. Cambie el estado del certificado de clave pública.
5. Proporcionar información sobre el estado actual del certificado de clave pública.
Desventajas de la PKI, ¿cuáles son?El defecto fundamental de PKI es la presencia de entidades confiables.
Los usuarios deben confiar incondicionalmente en la CA y CR. Pero, como muestra la práctica, la confianza incondicional conlleva graves consecuencias.
En los últimos diez años se han producido varios escándalos importantes en este ámbito relacionados con la vulnerabilidad de las infraestructuras.
— en 2010, el malware Stuxnet comenzó a difundirse en línea, firmado con certificados digitales robados de RealTek y JMicron.
- En 2017, Google acusó a Symantec de emitir una gran cantidad de certificados falsificados. En ese momento, Symantec era una de las CA más grandes en términos de volúmenes de producción. En el navegador Google Chrome 70, la compatibilidad con los certificados emitidos por esta empresa y sus centros afiliados GeoTrust y Thawte se detuvo antes del 1 de diciembre de 2017.
Las CA se vieron comprometidas y, como resultado, todos sufrieron: las propias CA, así como los usuarios y suscriptores. La confianza en la infraestructura se ha visto socavada. Además, los certificados digitales pueden bloquearse en el contexto de conflictos políticos, lo que también afectará al funcionamiento de muchos recursos. Esto es precisamente lo que se temía hace varios años en la administración presidencial rusa, donde en 2016 se discutió la posibilidad de crear un centro de certificación estatal que emitiría certificados SSL para sitios de RuNet. La situación actual es tal que incluso los portales estatales en Rusia certificados digitales emitidos por las empresas estadounidenses Comodo o Thawte (filial de Symantec).
Hay otro problema: la pregunta. autenticación primaria (autenticación) de usuarios. ¿Cómo identificar a un usuario que se ha puesto en contacto con la CA con una solicitud para emitir un certificado digital sin contacto personal directo? Ahora esto se soluciona situacionalmente dependiendo de las capacidades de la infraestructura. Algo se toma de registros abiertos (por ejemplo, información sobre personas jurídicas que solicitan certificados); en los casos en que los solicitantes sean personas físicas, se pueden utilizar oficinas bancarias u oficinas de correos, donde su identidad se confirma mediante documentos de identificación, por ejemplo, un pasaporte.
El problema de la falsificación de credenciales con fines de suplantación es fundamental. Tengamos en cuenta que no existe una solución completa a este problema por razones teóricas de la información: sin disponer de información fiable a priori, es imposible confirmar o negar la autenticidad de un objeto en particular. Como regla general, para la verificación es necesario presentar un conjunto de documentos que acrediten la identidad del solicitante. Existen muchos métodos de verificación diferentes, pero ninguno de ellos ofrece una garantía total de la autenticidad de los documentos. En consecuencia, tampoco puede garantizarse la autenticidad de la identidad del solicitante.
¿Cómo se pueden eliminar estas deficiencias?Si los problemas de PKI en su estado actual pueden explicarse por la centralización, entonces es lógico suponer que la descentralización ayudaría a eliminar parcialmente las deficiencias identificadas.
La descentralización no implica la presencia de entidades confiables - si crea infraestructura de clave pública descentralizada (Infraestructura de clave pública descentralizada, DPKI), entonces no se necesitan CA ni CR. Abandonemos el concepto de certificado digital y utilicemos un registro distribuido para almacenar información sobre claves públicas. En nuestro caso, llamamos registro a una base de datos lineal que consta de registros individuales (bloques) vinculados mediante la tecnología blockchain. En lugar de un certificado digital, introduciremos el concepto de “notificación”.
Cómo se verá el proceso de recepción, verificación y cancelación de notificaciones en la DPKI propuesta:
1. Cada solicitante presenta una solicitud de notificación de forma independiente completando un formulario durante el registro, después de lo cual crea una transacción que se almacena en un grupo especializado.
2. La información sobre la clave pública, junto con los datos del propietario y otros metadatos, se almacena en un registro distribuido, y no en un certificado digital, de cuya emisión en una PKI centralizada es responsable la CA.
3. La verificación de la autenticidad de la identidad del solicitante se realiza a posteriori mediante los esfuerzos conjuntos de la comunidad de usuarios de la DPKI, y no por el CR.
4. Sólo el propietario de dicha notificación puede cambiar el estado de una clave pública.
5. Cualquiera puede acceder al libro mayor distribuido y comprobar el estado actual de la clave pública.
Nota: La verificación comunitaria de la identidad de un solicitante puede parecer poco confiable a primera vista. Pero debemos recordar que hoy en día todos los usuarios de servicios digitales dejan inevitablemente una huella digital, y este proceso seguirá ganando impulso. Registros electrónicos abiertos de personas jurídicas, mapas, digitalización de imágenes del terreno, redes sociales: todas estas son herramientas disponibles públicamente. Ya se utilizan con éxito durante las investigaciones tanto de periodistas como de organismos encargados de hacer cumplir la ley. Por ejemplo, basta recordar las investigaciones de Bellingcat o del equipo conjunto de investigación JIT, que está estudiando las circunstancias del accidente del Boeing malasio.
Entonces, ¿cómo funcionaría en la práctica una infraestructura de clave pública descentralizada? Detengámonos en la descripción de la tecnología en sí, que patentado en 2018 y lo consideramos con razón nuestro know-how.
Imagine que hay un propietario que posee muchas claves públicas, donde cada clave es una determinada transacción que se almacena en el registro. En ausencia de una CA, ¿cómo se puede entender que todas las claves pertenecen a este propietario en particular? Para solucionar este problema se crea una transacción cero, que contiene información sobre el propietario y su billetera (de donde se debita la comisión por colocar la transacción en el registro). La transacción nula es una especie de “ancla” a la que se adjuntarán las siguientes transacciones con datos sobre claves públicas. Cada una de estas transacciones contiene una estructura de datos especializada o, en otras palabras, una notificación.
La notificación es un conjunto estructurado de datos que consta de campos funcionales e incluye información sobre la clave pública del propietario, cuya persistencia está garantizada mediante la colocación en uno de los registros asociados del registro distribuido.
La siguiente pregunta lógica es ¿cómo se forma una transacción cero? La transacción nula, como las posteriores, es una agregación de seis campos de datos. Durante la formación de una transacción cero, está involucrado el par de claves de la billetera (claves públicas y secretas emparejadas). Este par de claves aparece en el momento en que el usuario registra su billetera, de donde se debitará la comisión por colocar una transacción cero en el registro y, posteriormente, operaciones con notificaciones.
Como se muestra en la figura, se genera un resumen de clave pública de billetera aplicando secuencialmente las funciones hash SHA256 y RIPEMD160. Aquí RIPEMD160 es responsable de la representación compacta de datos, cuyo ancho no supera los 160 bits. Esto es importante porque el registro no es una base de datos barata. La clave pública en sí se ingresa en el quinto campo. El primer campo contiene datos que establecen una conexión con la transacción anterior. Para una transacción cero, este campo no contiene nada, lo que lo distingue de transacciones posteriores. El segundo campo son datos para verificar la conectividad de las transacciones. Para abreviar, llamaremos a los datos del primer y segundo campo "enlace" y "verificación", respectivamente. El contenido de estos campos se genera mediante hash iterativo, como se demuestra al vincular la segunda y tercera transacciones en la figura siguiente.
Los datos de los primeros cinco campos se certifican mediante una firma electrónica, que se genera utilizando la clave secreta de la billetera.
Eso es todo, la transacción nula se envía al grupo y, después de una verificación exitosa, se ingresa en el registro. Ahora puede "vincular" las siguientes transacciones. Consideremos cómo se forman las transacciones distintas de cero.
Lo primero que probablemente te llamó la atención es la abundancia de pares de claves. Además del ya conocido par de claves de billetera, se utilizan pares de claves ordinarias y de servicio.
Una clave pública ordinaria es para lo que se inició todo. Esta clave está involucrada en diversos procedimientos y procesos que se desarrollan en el mundo exterior (transacciones bancarias y de otro tipo, flujo de documentos, etc.). Por ejemplo, se puede utilizar una clave secreta de un par ordinario para generar firmas digitales para varios documentos (órdenes de pago, etc.), y se puede utilizar una clave pública para verificar esta firma digital con la posterior ejecución de estas instrucciones, siempre que es válida.
El par de servicios se emite al sujeto DPKI registrado. El nombre de este par corresponde a su finalidad. Tenga en cuenta que al formar/verificar una transacción cero, no se utilizan claves de servicio.
Aclaremos nuevamente el propósito de las claves:
- Las claves de billetera se utilizan para generar/verificar tanto una transacción nula como cualquier otra transacción no nula. La clave privada de una billetera solo la conoce el propietario de la billetera, que también es propietario de muchas claves públicas ordinarias.
- Una clave pública ordinaria tiene un propósito similar a una clave pública para la cual se emite un certificado en una PKI centralizada.
- El par de claves de servicio pertenece a DPKI. La clave secreta se emite a entidades registradas y se utiliza al generar firmas digitales para transacciones (excepto para transacciones cero). Público se utiliza para verificar la firma digital electrónica de una transacción antes de su publicación en el registro.
Por tanto, existen dos grupos de claves. El primero incluye claves de servicio y claves de billetera; solo tienen sentido en el contexto de DPKI. El segundo grupo incluye claves ordinarias; su alcance puede variar y está determinado por las tareas de la aplicación en las que se utilizan. Al mismo tiempo, DPKI garantiza la integridad y autenticidad de las claves públicas ordinarias.
Nota: El par de claves de servicio puede ser conocido por diferentes entidades DPKI. Por ejemplo, puede que sea igual para todos. Es por esta razón que al generar la firma de cada transacción distinta de cero, se utilizan dos claves secretas, una de las cuales es la clave de la billetera; solo la conoce el propietario de la billetera, que también es propietario de muchas transacciones ordinarias. claves públicas. Todas las claves tienen su propio significado. Por ejemplo, siempre es posible demostrar que la transacción fue inscrita en el registro por un sujeto registrado en la DPKI, ya que la firma también se generó en una clave de servicio secreto. Y no puede haber abusos, como ataques DOS, porque el propietario paga por cada transacción.
Todas las transacciones que siguen al cero uno se forman de manera similar: la clave pública (no la billetera, como en el caso de la transacción cero, sino un par de claves normal) se ejecuta a través de dos funciones hash SHA256 y RIPEMD160. Así se forman los datos del tercer campo. El cuarto campo contiene información adjunta (por ejemplo, información sobre el estado actual, fechas de vencimiento, marca de tiempo, identificadores de criptoalgoritmos utilizados, etc.). El quinto campo contiene la clave pública del par de claves de servicio. Con su ayuda se comprobará la firma digital, por lo que se replicará. Justifiquemos la necesidad de tal enfoque.
Recuerde que una transacción se ingresa en un grupo y se almacena allí hasta que se procesa. El almacenamiento en un pool conlleva cierto riesgo: los datos de la transacción pueden ser falsificados. El titular certifica los datos de la transacción con firma digital electrónica. La clave pública para verificar esta firma digital se indica explícitamente en uno de los campos de la transacción y posteriormente se ingresa en el registro. Las peculiaridades del procesamiento de transacciones son tales que un atacante puede cambiar los datos a su propia discreción y luego verificarlos usando su clave secreta, e indicar una clave pública emparejada para verificar la firma digital en la transacción. Si la autenticidad y la integridad se garantizan exclusivamente mediante la firma digital, dicha falsificación pasará desapercibida. Sin embargo, si además de la firma digital existe un mecanismo adicional que garantice tanto el archivo como la persistencia de la información almacenada, entonces se podrá detectar la falsificación. Para ello, basta con introducir en el registro la clave pública genuina del propietario. Expliquemos cómo funciona esto.
Deje que el atacante falsifique datos de transacciones. Desde el punto de vista de claves y firmas digitales, son posibles las siguientes opciones:
1. El atacante coloca su clave pública en la transacción mientras la firma digital del propietario permanece sin cambios.
2. El atacante crea una firma digital en su clave privada, pero no modifica la clave pública del propietario.
3. El atacante crea una firma digital en su clave privada y coloca una clave pública emparejada en la transacción.
Evidentemente las opciones 1 y 2 no tienen sentido, ya que siempre serán detectadas durante la verificación de la firma digital. Sólo la opción 3 tiene sentido, y si un atacante forma una firma digital en su propia clave secreta, entonces se ve obligado a guardar en la transacción una clave pública emparejada, diferente de la clave pública del propietario. Ésta es la única manera que tiene un atacante de imponer datos falsificados.
Supongamos que el propietario tiene un par de claves fijas: privada y pública. Deje que los datos se certifiquen mediante firma digital utilizando la clave secreta de este par y la clave pública se indique en la transacción. Supongamos también que esta clave pública se ha introducido previamente en el registro y se ha verificado de forma fiable su autenticidad. Entonces una falsificación se indicará por el hecho de que la clave pública de la transacción no corresponde a la clave pública del registro.
Vamos a resumir. Al procesar los primeros datos de transacción del propietario, es necesario verificar la autenticidad de la clave pública ingresada en el registro. Para ello, lea la clave del registro y compárela con la verdadera clave pública del propietario dentro del perímetro de seguridad (área de relativa invulnerabilidad). Si se confirma la autenticidad de la clave y se garantiza su persistencia en el momento de su colocación, entonces la autenticidad de la clave de la transacción posterior se puede confirmar/refutar fácilmente comparándola con la clave del registro. En otras palabras, la clave del registro se utiliza como muestra de referencia. Todas las demás transacciones de propietarios se procesan de manera similar.
La transacción se certifica mediante una firma digital electrónica; aquí es donde se necesitan claves secretas, y no una, sino dos a la vez: una clave de servicio y una clave de billetera. Gracias al uso de dos claves secretas, se garantiza el nivel necesario de seguridad; después de todo, otros usuarios pueden conocer la clave secreta del servicio, mientras que la clave secreta de la billetera solo la conoce el propietario del par de claves normal. A esta firma de dos claves la llamamos firma digital "consolidada".
La verificación de transacciones no nulas se realiza utilizando dos claves públicas: la billetera y la clave de servicio. El proceso de verificación se puede dividir en dos etapas principales: la primera es verificar el resumen de la clave pública de la billetera, y la segunda es verificar la firma digital electrónica de la transacción, la misma consolidada que se formó utilizando dos claves secretas ( billetera y servicio). Si se confirma la validez de la firma digital, luego de una verificación adicional la transacción se ingresa en el registro.
Puede surgir una pregunta lógica: ¿cómo comprobar si una transacción pertenece a una cadena específica con la "raíz" en forma de transacción cero? Para ello, el proceso de verificación se complementa con una etapa más: la verificación de la conectividad. Aquí es donde necesitaremos los datos de los dos primeros campos, que hasta ahora hemos ignorado.
Imaginemos que necesitamos comprobar si la transacción número 3 realmente viene después de la transacción número 2. Para hacer esto, utilizando el método de hash combinado, se calcula el valor de la función hash para los datos de los campos tercero, cuarto y quinto de la transacción número 2. Luego se realiza la concatenación de datos del primer campo de la transacción No. 3 y el valor de la función hash combinada previamente obtenido para los datos del tercer, cuarto y quinto campo de la transacción No. 2. Todo esto también se ejecuta a través de dos funciones hash SHA256 y RIPEMD160. Si el valor recibido coincide con los datos del segundo campo de la transacción número 2, se pasa la verificación y se confirma la conexión. Esto se muestra más claramente en las figuras siguientes.
En términos generales, la tecnología para generar e ingresar una notificación en el registro se ve exactamente así. En la siguiente figura se presenta una ilustración visual del proceso de formación de una cadena de notificaciones:
En este texto, no nos detendremos en los detalles, que sin duda existen, y volveremos a discutir la idea misma de una infraestructura de clave pública descentralizada.
Entonces, dado que el propio solicitante presenta una solicitud de registro de notificaciones, que no se almacenan en la base de datos de la CA, sino en el registro, se deben considerar los principales componentes arquitectónicos de DPKI:
1. Registro de notificaciones válidas (RDN).
2. Registro de notificaciones revocadas (RON).
3. Registro de notificaciones suspendidas (RPN).
La información sobre las claves públicas se almacena en RDN/RON/RPN en forma de valores de función hash. También vale la pena señalar que pueden ser registros diferentes, cadenas diferentes o incluso una cadena como parte de un registro único, cuando se ingresa información sobre el estado de una clave pública ordinaria (revocación, suspensión, etc.) en el cuarto campo de la estructura de datos en forma del valor de código correspondiente. Hay muchas opciones diferentes para la implementación arquitectónica de DPKI, y la elección de una u otra depende de varios factores, por ejemplo, criterios de optimización como el costo de la memoria a largo plazo para almacenar claves públicas, etc.
Por lo tanto, DPKI puede resultar, si no más simple, al menos comparable a una solución centralizada en términos de complejidad arquitectónica.
La pregunta principal sigue siendo: ¿Qué registro es adecuado para implementar la tecnología?
El principal requisito para el registro es la capacidad de generar transacciones de cualquier tipo. El ejemplo más famoso de libro mayor es la red Bitcoin. Pero al implementar la tecnología descrita anteriormente, surgen ciertas dificultades: las limitaciones del lenguaje de scripting existente, la falta de los mecanismos necesarios para procesar conjuntos arbitrarios de datos, métodos para generar transacciones de tipo arbitrario y mucho más.
En ENCRY intentamos resolver los problemas formulados anteriormente y desarrollamos un registro que, en nuestra opinión, tiene una serie de ventajas, a saber:
- admite varios tipos de transacciones: puede intercambiar activos (es decir, realizar transacciones financieras) y crear transacciones con una estructura arbitraria,
- los desarrolladores tienen acceso al lenguaje de programación propietario PrismLang, que proporciona la flexibilidad necesaria para resolver diversos problemas tecnológicos,
- Se proporciona un mecanismo para procesar conjuntos de datos arbitrarios.
Si adoptamos un enfoque simplificado, se produce la siguiente secuencia de acciones:
- El solicitante se registra en DPKI y recibe una billetera digital. La dirección de la billetera es el valor hash de la clave pública de la billetera. La clave privada de la billetera solo la conoce el solicitante.
- El sujeto registrado tiene acceso a la clave secreta del servicio.
- El sujeto genera una transacción cero y la verifica con una firma digital utilizando la clave secreta de la billetera.
- Si se forma una transacción distinta de cero, se certifica mediante una firma digital electrónica utilizando dos claves secretas: una billetera y una de servicio.
- El sujeto envía una transacción al grupo.
- El nodo de la red ENCRY lee la transacción del pool y verifica la firma digital, así como la conectividad de la transacción.
- Si la firma digital es válida y se confirma la conexión, prepara la transacción para su inscripción en el registro.
Aquí el registro actúa como una base de datos distribuida que almacena información sobre notificaciones válidas, canceladas y suspendidas.
Por supuesto, la descentralización no es una panacea. El problema fundamental de la autenticación del usuario primario no desaparece en ninguna parte: si actualmente la verificación del solicitante la realiza el CR, entonces en DPKI se propone delegar la verificación a los miembros de la comunidad y utilizar la motivación financiera para estimular la actividad. La tecnología de verificación de código abierto es bien conocida. La eficacia de dicha verificación ha quedado confirmada en la práctica. Recordemos de nuevo una serie de investigaciones de alto perfil realizadas por la publicación en línea Bellingcat.
Pero, en general, surge la siguiente imagen: DPKI es una oportunidad para corregir, si no todas, muchas de las deficiencias de la PKI centralizada.
Suscríbete a nuestro Habrablog, planeamos continuar cubriendo activamente nuestra investigación y desarrollo, y sigue , si no quieres perderte otras novedades sobre los proyectos ENCRY.
Fuente: habr.com