DPKI: abordando las desventajas de la PKI centralizada mediante blockchain

Los certificados digitales son una de las herramientas auxiliares más conocidas que ayudan a proteger los datos en las redes públicas. Sin embargo, la desventaja clave de esta tecnología también se conoce comúnmente: los usuarios se ven obligados a confiar implícitamente en las autoridades de certificación que emiten certificados digitales. Andrey Chmora, Director de Tecnología e Innovaciones de ENCRY, sugirió un nuevo enfoque para construir una Infraestructura de Clave Pública (PKI) para eliminar las desventajas existentes utilizando la tecnología de contabilidad distribuida (blockchain).
Comencemos con lo básico.

Si ya conoce los conceptos básicos de la infraestructura de clave pública existente y sus desventajas clave, no dude en desplazarse hacia abajo hasta la descripción de lo que sugerimos cambiar.





Entonces, ¿cómo funcionará en la práctica una infraestructura descentralizada de clave pública? Profundicemos en la tecnología que hemos patentado en 2018 y consideremos nuestro mejor conocimiento.

Supongamos que hay un individuo que posee un conjunto de claves públicas, donde cada clave es una especie de transacción almacenada en un libro mayor. ¿Cómo verificar que todas estas claves realmente pertenecen a un propietario determinado sin una CA? Para resolver esta tarea, podemos crear una transacción nula para almacenar la información sobre el propietario y su billetera electrónica (de la cual se cobra una tarifa de comisión por agregar una transacción al libro mayor). Una transacción nula es una especie de "ancla" para conectar las próximas transacciones junto con los datos sobre claves públicas. Cada transacción de este tipo contiene una estructura de datos especializada que se denomina "notificación".

La notificación es un conjunto de datos estructurados de campos funcionales que almacena información sobre la clave pública del propietario y garantiza la persistencia de esta clave al agregarla a uno de los registros relacionados en el libro mayor distribuido.

La siguiente pregunta obvia es ¿cómo formar una transacción nula? Una transacción nula, al igual que todas las transacciones posteriores, es una agregación de seis campos de datos. Para formar una transacción nula, utilizamos el par de claves pública / privada para la billetera electrónica. Este par de claves pública / privada se crea cuando el usuario crea su billetera desde la cual se cobrará la tarifa de comisión por agregar una transacción nula al libro mayor y para las operaciones posteriores con notificaciones.


Figura 3. Crear una transacción nula

La Figura 3 muestra cómo se forma un resumen de la clave pública de la billetera electrónica utilizando la función hash SHA256 y luego la función hash RIPEMD160. Aquí, RIPEMD160 es responsable de representar datos con un tamaño de resumen de hasta 160 bits. Es muy importante, ya que los libros de contabilidad son bases de datos caras. La clave pública en sí está incluida en el quinto campo. El primer campo contiene datos que vinculan una transacción dada a la anterior. En la transacción nula, a diferencia de todas las demás transacciones, este campo está vacío. El segundo campo contiene datos para la verificación de la conectividad de la transacción. En aras de la brevedad, nos referiremos a los datos en el primer y segundo campo como "enlace" y "verificación" respectivamente.


Figura 4. Transacciones vinculantes y verificación

Los datos en estos campos se pueden formar utilizando hashing iterativo como se muestra en la Figura 4 anterior para vincular la segunda y la tercera transacción.
Los datos en los primeros cinco campos se autentican con el DS generado utilizando la clave privada de la billetera electrónica. Y eso es todo: la transacción ahora se puede agregar al grupo y luego, después de una verificación exitosa (como se muestra en la Figura 5 ), al libro mayor.


Figura 5. Verificación de la transacción nula

Ahora esta transacción se puede utilizar para "conectar" las próximas transacciones. Echemos un vistazo a la Figura 6 para ver cómo se forman todas las transacciones no nulas.


Figura 6. Crear una transacción no nula

Lo primero que puede notar es una multitud de pares de claves públicas / privadas. Además del ya familiar par de claves públicas / privadas de monedero electrónico, también utilizamos pares de claves ordinarias y de servicio.

Una clave pública ordinaria es la parte más importante aquí. Esta clave se utiliza en diversos procedimientos y procesos del mundo circundante (como transacciones bancarias y otras, flujo de documentos, etc.). Por ejemplo, una clave privada de un par de claves pública / privada ordinaria se puede usar para crear un DS para varios documentos, como órdenes de pago, mientras que la clave pública se puede usar para verificar el DS con la posterior ejecución de estos ordenes.

Se emite un par de claves de servicio público / privado a una entidad DPKI registrada. El nombre de este par de claves pública / privada refleja claramente su propósito. Tenga en cuenta que las claves de servicio no se utilizan para generar / verificar una transacción nula.

Para ser claros, refinemos los propósitos de estas claves:

1. Las claves de monedero electrónico se utilizan para la generación y / o verificación de transacciones nulas y no nulas. La clave privada de la billetera electrónica es conocida solo por el propietario de la billetera electrónica que también posee el conjunto de claves públicas ordinarias.
2. El propósito de una clave pública ordinaria es el mismo que el de la clave pública para la cual se emite un certificado en la PKI centralizada.
3. El par de claves de servicio público / privado pertenece al DPKI. Se emite una clave privada para las entidades registradas y se utiliza para crear un DS de todas las transacciones no nulas. Se utiliza una clave pública para la verificación de un DS para las transacciones antes de agregarlas al libro mayor.

Por lo tanto, tenemos dos grupos de claves. El primer grupo incluye claves de servicio y claves de monedero electrónico que son elegibles solo dentro del DPKI. El segundo grupo incluye claves ordinarias que se pueden utilizar para diversos fines según un campo de aplicación determinado. Al mismo tiempo, el DPKI garantiza la integridad y autenticidad de las claves públicas ordinarias.

Nota: El par de claves de servicio público / privado puede divulgarse a varias entidades DPKI. En ciertos casos, el par puede ser el mismo para todas las entidades. Es por eso que formar una firma para cada transacción no nula requiere dos claves privadas, una de las cuales es la clave de billetera electrónica: esta clave es conocida solo por el propietario de la billetera electrónica que también posee el conjunto de claves públicas ordinarias. Todas estas claves tienen ciertos propósitos. Por ejemplo, siempre podemos probar que una entidad DPKI registrada incluyó una transacción determinada en el libro mayor, ya que la firma también se formó utilizando una clave privada de servicio. Además, esto evita cualquier ataque de DOS y otras actividades fraudulentas, porque el propietario paga por cada transacción.

Todas las transacciones que siguen a una transacción nula se forman de manera similar: una clave pública (de un par de claves ordinarias, no la clave de la billetera electrónica como para las transacciones nulas) se procesa utilizando dos funciones hash: SHA256 y RIPEMD160. Así es como se forman los datos en el tercer campo. El cuarto campo contiene información adicional (por ejemplo, información sobre el estado actual, período de validez, marca de tiempo, ID de los algoritmos criptográficos, etc.). El quinto campo contiene una clave pública del servicio par de claves pública / privada. Esta clave se replica, ya que se utilizará para la verificación de un DS. Probemos que tal enfoque es necesario.

Cada transacción se incluye en el grupo y se almacena allí hasta que se procesa. Sin embargo, mantener las transacciones en el grupo es arriesgado, ya que los datos de las transacciones pueden falsificarse. El propietario autentica los datos de la transacción utilizando un DS. La clave pública para la verificación de este DS se especifica explícitamente en uno de los campos de transacción y luego se incluye en el libro mayor. Las transacciones se procesan de una manera que posiblemente permita a un atacante modificar los datos a su propia discreción, verificarlos con su propia clave privada y luego especificar la clave pública correspondiente para la verificación de DS directamente en la transacción. Si se garantiza la autenticidad e integridad solo con un DS, dicha falsificación puede pasar desapercibida. Sin embargo, extender un DS con un mecanismo adicional que proporcione tanto el archivado como la persistencia de la información almacenada ayudará a detectar dicha falsificación. Todo lo que tenemos que hacer es incluir la clave pública auténtica del propietario en el libro mayor. Veamos como funciona.

Supongamos que un atacante está tratando de falsificar los datos de la transacción. En términos de claves y DS, son posibles las siguientes opciones:

1. El atacante coloca su propia clave pública en la transacción mientras mantiene el DS del propietario sin cambios.
2. El atacante forma un nuevo DS utilizando su propia clave privada mientras mantiene la clave pública del propietario sin cambios.
3. El atacante forma un nuevo DS utilizando su propia clave privada y coloca la clave pública correspondiente en la transacción.

Es obvio que las opciones 1 y 2 son inútiles, ya que la verificación del DS siempre detectará dicha falsificación. La única opción que tiene sentido es la opción 3: si el atacante crea un DS utilizando su propia clave privada, se verá obligado a guardar la clave pública correspondiente en la transacción, y esta clave será diferente de la clave pública del propietario. Es la única forma para que el atacante haga cumplir sus datos falsificados.

Supongamos que el propietario tiene un par de claves público / privado fijo. Suponga que los datos se autentican con un DS utilizando una clave privada de este par mientras la clave pública se especifica en la transacción. Supongamos también que esta clave pública se ha incluido previamente en el libro mayor y se ha autenticado por completo. Entonces, la falsificación puede revelarse por el hecho de que la clave pública en la transacción no coincide con la clave pública en el libro mayor.

Resumámoslo. Al procesar datos de la primera transacción del propietario, debemos autenticar la clave pública incluida en el libro mayor. Para hacer esto, podemos leer la clave del libro mayor y luego hacerla coincidir con la clave pública auténtica del propietario dentro del perímetro de seguridad (área relativamente invulnerable). Si la clave colocada está autenticada y es totalmente persistente, entonces la clave de la próxima transacción también se puede autenticar fácilmente al hacerla coincidir con la clave del libro mayor. En otras palabras, la clave del libro mayor se usa como referencia. Todas las demás transacciones del propietario se procesarán de manera similar.

Cada transacción se autentica con un DS, y aquí necesitamos ambas claves privadas: la clave privada del servicio y la clave privada de la billetera electrónica. Con base en las dos claves privadas, podemos garantizar el nivel de seguridad objetivo, ya que la clave privada del servicio puede ser conocida por otros usuarios, mientras que la clave privada de la billetera electrónica es conocida solo por el propietario del par de claves ordinarias. Llamamos a esta firma de dos claves un DS "consolidado".

Las transacciones no nulas se verifican utilizando las dos claves públicas: la clave de la billetera electrónica y la clave de servicio. (Figura 7)


Figura 7. Verificación de una transacción no nula

El proceso de verificación consta de los dos pasos básicos: el primer paso incluye la verificación del resumen de la clave pública de la billetera electrónica, mientras que el segundo paso implementa la verificación del DS "consolidado" de la transacción formado usando las dos claves privadas (es decir, el e- clave de billetera y la clave de servicio). Cuando el DS se autentica, la transacción correspondiente, tras la verificación adicional, se incluye en el libro mayor.

Sin embargo, surge la siguiente pregunta: ¿cómo verificar si una transacción dada pertenece a una cadena de transacción particular que comienza con una transacción nula? Para hacer esto, hemos actualizado el proceso de verificación con otro paso más: la verificación de conectividad. Este paso requerirá datos de los dos primeros campos que no hemos usado hasta este momento.

Supongamos que necesitamos verificar si la transacción # 2 es realmente seguida por la transacción # 3 . Para hacer esto, podemos usar el método combinado de hash para calcular los valores de la función hash para los datos en los campos tercero, cuarto y quinto. Podemos concatenar los datos del primer campo de la transacción # 3 y el valor de la función hash combinada previamente calculada para los datos en los campos tercero, cuarto y quinto de la transacción # 2 . Todos estos valores se procesan utilizando las dos funciones hash: SHA256 y RIPEMD160. Si el valor resultante coincide con los datos en el segundo campo de la transacción # 2 , entonces la verificación se pasa con éxito y se prueba la conectividad. Esto se muestra con más detalle en las siguientes figuras.




Figura 8, Figura 9. Verificación vinculante, ejemplo de segunda y tercera transacción

En general, formar e incluir una notificación en el libro mayor se ve así. El flujo de trabajo de formar una cadena de notificaciones se muestra claramente en la siguiente figura:


Figura 10. Estructura y procesamiento de la transacción.

En este artículo, no profundizaremos en los detalles y volveremos a la discusión del concepto de infraestructura descentralizada para claves públicas.

Entonces, dado que la entidad que realiza la solicitud envía una solicitud de registro de notificaciones que se almacenan en el libro mayor en lugar de en una base de datos de CA, los componentes arquitectónicos centrales del DPKI son los siguientes:

1. Libro mayor de notificaciones válidas (LVN)
2. Libro mayor de notificaciones retiradas (LWN)
3. Libro mayor de notificaciones suspendidas (LSN).

La información sobre las claves públicas se almacena en LVN / LWN / LSN como valores de función hash. Tenga en cuenta también que puede ser libros de contabilidad diferentes o cadenas diferentes o incluso una sola cadena como parte de un libro de contabilidad único, cuando se agrega información sobre el estado de una clave pública ordinaria (retiro, suspensión, etc.) al cuarto campo del estructura de datos como el valor del código correspondiente. Hay muchas opciones para la implementación arquitectónica del DPKI dependiendo de varios criterios de optimización, como los costos para el almacenamiento a largo plazo de claves públicas en la memoria, etc.

Por lo tanto, el DPKI puede convertirse en una complejidad arquitectónica igual o incluso menor en comparación con una solución centralizada.

Entonces, la pregunta principal aquí es ¿ qué libro mayor es más adecuado para implementar esta tecnología?

El requisito central para el libro mayor es poder formar transacciones de cualquier tipo. El ejemplo más conocido de un libro mayor real es Bitcoin. Sin embargo, la implementación de la tecnología anterior para Bitcoin puede enfrentar ciertas dificultades: limitaciones del lenguaje de secuencias de comandos existente, la falta de mecanismos necesarios para procesar conjuntos de datos arbitrarios y métodos para generar transacciones de tipos arbitrarios, y así sucesivamente.

En ENCRY intentamos resolver los problemas anteriores y desarrollamos un libro mayor que, en nuestra opinión, presenta varias ventajas importantes:

• Soporte de varios tipos de transacciones: en este libro mayor, puede intercambiar activos (es decir, realizar transacciones financieras) y formar transacciones de una estructura arbitraria
• Los desarrolladores pueden utilizar el lenguaje de programación patentado PrismLang, que es muy flexible para resolver diversos problemas tecnológicos.
• El mecanismo implementado para procesar conjuntos de datos arbitrarios.

En pocas palabras, se deben completar los siguientes pasos:

1. Una entidad que realiza la solicitud se registra en el DPKI y obtiene una billetera electrónica. La dirección de la billetera electrónica es un valor de la función hash aplicada a la clave pública de la billetera electrónica. La clave privada de la billetera electrónica solo es conocida por la entidad que realiza la solicitud
2. Al registrarse, la entidad obtiene acceso a la clave privada del servicio
3. La entidad forma una transacción nula y luego autentica su DS utilizando la clave privada de la billetera electrónica
4. Al formar una transacción no nula, la entidad debe autenticar su DS utilizando dos claves privadas: la clave de la billetera electrónica y la clave de servicio
5. La entidad envía la transacción al grupo
6. El nodo de red ENCRY lee la transacción del grupo y luego verifica el DS y la conectividad de la transacción
7. Si el DS es válido y se prueba la conectividad, el nodo preparará la transacción para agregarla al libro mayor.

Aquí, el libro mayor sirve como una base de datos distribuida que almacena información sobre notificaciones válidas, retiradas y suspendidas.

Ciertamente, la descentralización no es una solución única para todos. El problema central con la autenticación del usuario principal aún persiste: mientras que la entidad que realiza la solicitud actualmente es verificada por la CA, el DPKI propone delegar esta verificación a los miembros de la comunidad y motivarlos financieramente. La tecnología de verificación basada en fuentes públicas es comúnmente conocida. La eficacia de dicha verificación también se ha demostrado en la práctica: varias investigaciones de alto perfil realizadas por Bellingcat son buenos ejemplos de esto.

Pero, en general, estamos bastante seguros de que el DPKI es capaz de eliminar muchas, si no todas, las desventajas de una PKI centralizada.

Siéntase libre de suscribirse a nuestro blog en Habr , donde discutiremos nuestras futuras investigaciones y desarrollos, y siga nuestro Twitter para estar atento a más noticias sobre los proyectos de ENCRY.