No es ningún secreto que una de las herramientas auxiliares comunes, sin las cuales la protección de datos en redes abiertas es imposible, es la tecnología de los certificados digitales. Sin embargo, no es un secreto que el principal inconveniente de esta tecnología es la confianza incondicional en los centros que emiten certificados digitales. Andrey Chmora, Director de Tecnología e Innovación de ENCRY, ha propuesto un nuevo enfoque para organizar la Infraestructura de clave pública (
PKI ), que ayudará a eliminar las deficiencias actuales y que utiliza tecnología de registro distribuido (blockchain). Pero lo primero es lo primero.
Si está familiarizado con los principios operativos de la infraestructura existente de claves públicas y conoce sus deficiencias clave, puede pasar inmediatamente a la descripción de lo que proponemos cambiar.¿Qué son las firmas y certificados digitales?La interacción en Internet siempre implica la transferencia de datos. Todos estamos interesados en garantizar que los datos se transmitan de manera segura. ¿Pero qué es la seguridad? Los servicios de seguridad más solicitados son confidencialidad, integridad y autenticidad. Para esto, actualmente se utilizan métodos de criptografía asimétrica, o criptografía con una clave pública.
Para comenzar, para utilizar estos métodos, los sujetos de interacción deben tener dos claves de pares individuales: pública y secreta. Con su ayuda, se proporcionan los servicios de seguridad que mencionamos anteriormente.
¿Cómo se logra la confidencialidad de la transmisión de información? Antes de enviar datos, el suscriptor que envía encripta (convierte criptográficamente) datos abiertos utilizando la clave pública del destinatario, y el remitente desencripta el texto cifrado recibido utilizando un par de claves secretas.
¿Cómo se logra la integridad y autenticidad de la información transmitida? Para resolver este problema, se creó otro mecanismo. Los datos abiertos no están encriptados, pero con ellos se encripta el resultado de aplicar una función hash criptográfica (una imagen "comprimida" de la secuencia de datos de entrada). El resultado de dicho hash se denomina "resumen", y su cifrado se realiza en la clave secreta del suscriptor emisor ("testigo"). El cifrado implícito da como resultado una firma digital. Este, junto con el texto plano, se transmite al suscriptor-receptor ("revisor"). Descifra la firma digital en la clave pública del testigo y la compara con el resultado de aplicar la función de cifrado hash, que el verificador calcula de forma independiente en función de los datos abiertos recibidos. Si coinciden, esto indica que los datos fueron transmitidos en una forma auténtica e integral precisamente por el suscriptor emisor, y no modificado por el atacante.
La mayoría de los recursos que trabajan con datos personales e información de pago (bancos, compañías de seguros, compañías aéreas, 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 él? Todo es simple En el primer y en el segundo proceso, las claves públicas están involucradas, y dado que desempeñan un papel central, es muy importante asegurarse de que las claves realmente pertenezcan al remitente (el testigo, en caso de verificación de firma) o al destinatario, y no se reemplacen con las claves de los atacantes. Para ello, existen certificados digitales que pueden garantizar la autenticidad e integridad de la clave pública.
Nota: la autenticidad e integridad de una clave pública se verifica exactamente de la misma manera que la autenticidad e integridad de los datos abiertos, es decir, utilizando una firma digital electrónica (EDS). ¿De dónde vienen los certificados digitales?La emisión y el mantenimiento de certificados digitales es responsabilidad de las autoridades de certificación de confianza o de las Autoridades de certificación (CA). El solicitante solicita la emisión de un certificado en la CA, pasa la identificación en el Centro de Registro (CR) y recibe un certificado en la CA. La CA garantiza que la clave pública del certificado pertenece a la misma entidad para la que se emitió.
Si no confirma la autenticidad de la clave pública, el atacante durante la transferencia / almacenamiento de esta clave puede reemplazarla por la suya. Si la sustitución tuvo lugar, el atacante podrá descifrar todo lo que el suscriptor que envía transmite al destinatario, o cambiar los datos abiertos a su discreción.
Los certificados digitales se utilizan donde haya criptografía asimétrica. Uno de los certificados digitales más comunes son los certificados SSL para el modo seguro de interacción a través del protocolo HTTPS. Cientos de compañías registradas en varias jurisdicciones se dedican a la emisión de certificados SSL. La participación principal recae en cinco a diez grandes centros de confianza: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA y CR son componentes PKI, que también incluyen:
- Open Directory : una base de datos de acceso público que proporciona almacenamiento confiable de certificados digitales.
- La lista de revocación de certificados es una base de datos de acceso público que proporciona un almacenamiento confiable de certificados digitales de claves públicas revocadas (por ejemplo, debido al compromiso de una clave secreta privada). Los actores de la infraestructura pueden acceder a esta base de datos por su cuenta, o pueden usar el Protocolo de estado de certificación en línea (OCSP) especializado, que simplifica el proceso de verificación.
- Usuarios certificados : PKI atiende a entidades que han firmado un acuerdo de usuario con la CA y verifican la firma digital y / o cifran los datos en función de una clave pública del certificado.
- Los suscriptores son entidades atendidas por PKI que poseen una clave privada, un par de claves públicas del certificado y han firmado un acuerdo de suscriptor con la CA. El suscriptor puede ser un usuario del certificado al mismo tiempo.
Por lo tanto, las entidades de confianza de la infraestructura de clave pública, que incluyen CA, CR y directorios abiertos, son responsables de:
1. Verificación de la identidad del solicitante.
2. Perfilado de un certificado de clave pública.
3. Emisión de un certificado de clave pública para el solicitante, cuya identidad se verifica auténticamente.
4. Cambiar el estado de un certificado de clave pública.
5. Proporcionar información sobre el estado actual del certificado de clave pública.
Desventajas de PKI, ¿cuáles son?Un inconveniente fundamental de PKI es la presencia de entidades confiables.
Los usuarios ciertamente deben confiar en la CA y el MD . Pero, como muestra la práctica, la confianza incondicional está cargada de graves consecuencias.
En los últimos diez años, se han producido varios escándalos importantes relacionados con la vulnerabilidad de la infraestructura en esta área.
- En 2010, el malware Stuxnet comenzó a extenderse en la red, que se firmó 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 principales CA en términos de producción. En el navegador Google Chrome 70, el soporte para los certificados emitidos por esta empresa y sus filiales GeoTrust y Thawte se suspendió hasta el 1 de diciembre de 2017.Las CA se vieron comprometidas, como resultado, todos sufrieron, tanto las propias CA como los usuarios y suscriptores. La confianza en la infraestructura fue socavada. Además, los certificados digitales pueden bloquearse en conflictos políticos, lo que también afectará el trabajo de muchos recursos. Esto fue precisamente lo que se temía hace varios años en la administración del presidente ruso, donde en 2016 discutieron la posibilidad de crear un centro de certificación estatal que emitiera certificados SSL a los sitios web en Runet. El estado actual de las cosas es tal que incluso los portales estatales en Rusia
usan certificados digitales emitidos por las compañías estadounidenses Comodo o Thawte (la "hija" de Symantec).
Hay otro problema: el problema de
la autenticación primaria (autenticación) de los usuarios . ¿Cómo identificar a un usuario que ha solicitado la CA con una solicitud de certificado digital sin contacto personal directo? Ahora esto se decide situacionalmente dependiendo de las capacidades de la infraestructura. Se toma algo de los registros abiertos (por ejemplo, información sobre entidades legales que solicitan certificados), en los casos en que los solicitantes son personas físicas, se pueden utilizar oficinas bancarias u oficinas postales, donde su identidad se confirma mediante documentos de identificación, por ejemplo, un pasaporte.
El problema de la falsificación de credenciales con el propósito de suplantación pertenece a la categoría de las fundamentales. Tenga en cuenta que no existe una solución completa a este problema debido a razones teóricas de la información: sin información confiable a priori, es imposible confirmar o negar la autenticidad de un tema en particular. Como regla, para la verificación es necesario presentar un conjunto de documentos que prueben la identidad del solicitante. Existen muchos métodos de verificación diferentes, pero ninguno de ellos ofrece una garantía completa de la autenticidad de los documentos. En consecuencia, tampoco se puede garantizar la autenticidad de la identidad del solicitante.
¿Cómo se pueden eliminar estas deficiencias?Si los problemas de PKI en su situación actual pueden explicarse por la centralización, es lógico suponer que la descentralización ayudaría a eliminar parcialmente las deficiencias indicadas.
La descentralización no implica la presencia de actores confiables: si crea una infraestructura descentralizada de claves públicas (Infraestructura de clave pública descentralizada, DPKI ), entonces no necesita una CA o una oficina central . Renunciamos al concepto de un certificado digital y usamos un registro distribuido para almacenar información sobre claves públicas. En nuestro caso, llamamos a un registro una base de datos lineal que consta de registros separados (bloques) conectados por la tecnología blockchain. En lugar de un certificado digital, presentamos el concepto de "notificación".
Cómo se verá el proceso de recepción, verificación y cancelación de notificaciones en el DPKI propuesto:
1. Cada solicitante envía una solicitud de notificación por su cuenta completando un formulario durante el registro, después de lo cual forma una transacción que se almacena en un grupo especializado.
2. La información sobre la clave pública junto con los detalles del propietario y otros metadatos se almacenan en un registro distribuido, y no en un certificado digital, del cual CA es responsable de emitir en una PKI centralizada.
3. La identidad del solicitante se verifica después del hecho por los esfuerzos conjuntos de la comunidad de usuarios de DPKI, no del CR.
4. Solo el propietario de dicha notificación puede cambiar el estado de una clave pública.
5. Todos pueden acceder al registro distribuido y verificar el estado actual de la clave pública.
Nota: a primera vista, la verificación de identidad de la comunidad puede parecer poco confiable. Pero debemos recordar que en la actualidad, todos los usuarios de servicios digitales ciertamente dejarán una huella digital, y este proceso solo continuará ganando fuerza. Los registros electrónicos abiertos de entidades legales, mapas, digitalización de imágenes de terreno, redes sociales son herramientas disponibles públicamente. Ya se utilizan con éxito en investigaciones tanto de periodistas como de agencias de aplicación de la ley. Por ejemplo, es suficiente recordar las investigaciones de Bellingcat o el grupo conjunto de investigación JIT, que estudia las circunstancias del accidente del Boeing de Malasia.
Entonces, ¿cómo funcionará en la práctica una infraestructura descentralizada de clave pública? Detengámonos en la descripción de la tecnología en sí, que
patentamos en 2018 y consideremos con razón nuestro conocimiento.
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. ¿Cómo, en ausencia de una CA, entender que todas las claves pertenecen a este propietario en particular? Para resolver este problema, se crea una transacción cero, que contiene información sobre el propietario y su billetera (de la cual se carga la comisión por colocar la transacción en el registro). Una transacción cero es una especie de "ancla" a la que se adjuntarán las siguientes transacciones con datos sobre claves públicas. Cada una de esas transacciones contiene una estructura de datos especializada, o de otra manera, una notificación.
La notificación es un conjunto de datos estructurados que consta de campos funcionales e incluye información sobre la clave pública del propietario, cuya persistencia está garantizada por la colocación en una de las entradas relacionadas del registro distribuido.La siguiente pregunta lógica es ¿cómo se forma una transacción cero? Una transacción cero, como las posteriores, es una agregación de seis campos de datos. Durante la formación de una transacción cero, se involucra un par de claves de la billetera (claves públicas y claves secretas de pares). Este par de claves aparece en el momento en que el usuario registra su billetera, de la cual se debitará la comisión por publicar una transacción cero en el registro y, posteriormente, las operaciones con notificaciones.
Como se muestra en la figura, el resumen de la clave de billetera pública se genera aplicando sucesivamente las funciones hash SHA256 y RIPEMD160. Aquí, RIPEMD160 es responsable de la presentación compacta de datos cuya capacidad de bits no excede los 160 bits. Esto es importante, porque el registro no es una base de datos barata. La clave pública en sí misma 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 las transacciones posteriores. El segundo campo son los datos para verificar la conectividad de la transacción. Por brevedad, llamaremos a los datos del primer y segundo campo "paquete" y "verificación", respectivamente. El contenido de estos campos se genera mediante el método de hashing iterativo como se muestra en el ejemplo de vinculación de la segunda y la tercera transacción en la figura a continuación.
Los datos de los primeros cinco campos están certificados por una firma digital electrónica, que se genera utilizando la clave secreta de la billetera.
Todo, la transacción cero se envía al grupo y después de una verificación exitosa (como se muestra en la figura a continuación) se ingresa en el registro.
Ahora puede "vincular" las siguientes transacciones. Considere cómo se produce la formación de transacciones distintas de cero.
Lo primero que probablemente te llamó la atención fue la abundancia de pares de claves. Además del par de llaves ya familiar de la billetera, se usan pares de llaves ordinarios y oficiales.
Una clave pública ordinaria es aquella para la cual todo, de hecho, se inició. Esta clave está involucrada en varios procedimientos y procesos que se desarrollan en el mundo circundante (transacciones bancarias y otras, flujo de documentos, etc.). Por ejemplo, una clave secreta de un par ordinario se puede usar para generar firmas digitales de varios documentos (órdenes de pago, etc., y disponibles públicamente) para verificar esta firma digital con la posterior ejecución de estas órdenes, sujeto a su validez.
Se emite un par comercial a una entidad DPKI registrada. El nombre de este par corresponde a su propósito. Tenga en cuenta que al generar / verificar una transacción cero, las claves de servicio no se utilizan.
Una vez más, aclararemos el propósito de las claves:
- Las claves de billetera se usan para generar / verificar tanto una transacción cero como cualquier otra transacción que no sea cero. La clave secreta de la billetera es conocida solo por el propietario de la billetera, quien al mismo tiempo es el propietario de muchas claves públicas ordinarias.
- Una única clave pública es similar en propósito a una clave pública para la cual se emite un certificado en una PKI centralizada.
- El par de claves de servicio es propiedad de DPKI. La clave secreta se emite a las entidades registradas y se utiliza en la formación de transacciones digitales electrónicas (con la excepción de cero). Público se utiliza para verificar la firma digital de una transacción antes de colocarla en el registro.
Por lo tanto, hay 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 se debe a las aplicaciones en las que se utilizan. Al mismo tiempo, DPKI garantiza la integridad y autenticidad de las claves públicas ordinarias.
Nota: Un par de claves de servicio puede ser conocido por varias entidades DPKI. Por ejemplo, puede ser igual para todos. Por esta razón, al generar la firma de cada transacción que no sea 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 claves públicas comunes. Todas las claves tienen su propio significado. Por ejemplo, siempre puede probar que una entidad DPKI registrada ingresó una transacción en el registro, ya que la firma se generó incluso en una clave de servicio secreta. Y no puede haber abuso, como un ataque de DOS, porque el propietario paga por cada transacción.Todas las transacciones que siguen al cero se generan de manera similar: una clave pública (pero no una billetera, como en el caso de una transacción cero, pero de un par de claves ordinarias) se ejecuta a través de dos funciones hash SHA256 y RIPEMD160. Entonces se forman los datos del tercer campo. La información de acompañamiento se ingresa en el cuarto campo (por ejemplo, información sobre el estado actual, los períodos de validez, la marca de tiempo, los identificadores de los algoritmos criptográficos utilizados, etc.). En el quinto campo, la clave pública del par de claves de servicio. Con su ayuda, se verificará el EDS, por lo que se replica. Justificamos la necesidad de tal enfoque.
Recuerde que una transacción se ingresa en el grupo y se almacena allí hasta que se procesa. El almacenamiento en el grupo está asociado con un cierto riesgo: estas transacciones pueden falsificarse. El propietario certifica los datos de la transacción de firma digital. La clave pública para verificar esta firma digital se indica en uno de los campos de transacción en forma explícita y posteriormente se ingresa en el registro. , , . , . , , , . . , .
. :
1. .
2. , .
3. .
, 1 2 , . 3, , , . .
, — . , . , . , .
. . ( ). , / . , . .
— - , , — . — , . “” .
, , : . : — , — , , , ( ). , .
: “” ? — . - , .
, , №3 №2. - , №2. №3 - , №2. - SHA256 RIPEMD160. №2, . .
. :
, , , , .
, , , , DPKI :
1. ().
2. ().
3. ().
// -. , , , (, .) . DPKI , , , .
, DPKI , .
—
?— . — . : , , , .
ENCRY , , , , :
, :
- DPKI . — - . .
- .
- .
- , : .
- .
- ENCRY , .
- , .
, , .
, . : , DPKI , . . . - Bellingcat.
: DPKI — , , PKI.
, ,
, ENCRY.