La Fundación Linux, BastionZero y Docker han presentado un nuevo proyecto de código abierto llamado OpenPubKey, que desarrolla el protocolo criptográfico homónimo para certificar digitalmente diversos objetos. La tecnología ha sido creada como un proyecto conjunto de BastionZero y Docker con el objetivo de simplificar la certificación digital de las imágenes de contenedores Docker para evitar su suplantación y confirmar la construcción por parte del creador declarado. El proyecto se desarrollará en una plataforma neutral bajo la tutela de la Fundación Linux, lo que eliminará la dependencia de empresas comerciales individuales y facilitará la colaboración con participantes externos. La implementación de referencia de OpenPubKey está escrita en Go y se distribuye bajo la licencia Apache 2.0.
Las capacidades de OpenPubKey no se limitan solo a las imágenes de contenedores; la tecnología puede aplicarse para confirmar la fuente de obtención de cualquier recurso, prevenir la suplantación de dependencias y aumentar la seguridad de los canales de distribución de conjuntos de datos. Por ejemplo, la tecnología es aplicable para certificar compilaciones de programas, mensajes individuales y confirmaciones (commits). Los creadores de la firma solo necesitan tener una cuenta en un servicio que soporte OpenID, mientras que a los consumidores se les proporciona la posibilidad de verificar las firmas adjuntas y confirmar su relación con el identificador OpenID declarado.
Por su propósito, OpenPubKey es similar a la sistema Sigstore creado en Google y previamente transferido a la Fundación Linux, pero se diferencia de este por su notable simplificación en la implementación, uso y mantenimiento al eliminar componentes de servidor centralizados responsables de mantener un registro público que confirme la autenticidad de los cambios (transparency log) y facilitar el funcionamiento de las autoridades certificadoras (Certificate Authority).
En lugar de implementar sus propias autoridades certificadoras, OpenPubKey utiliza la autenticación mediante la tecnología OpenID y vincula las firmas generadas a los proveedores existentes de OpenID Connect. En otras palabras, OpenPubKey permite asociar claves criptográficas a usuarios específicos utilizando proveedores de OpenID Connect (IdP) en lugar de autoridades certificadoras. La tecnología es completamente compatible con proveedores existentes de OpenID, como GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak y Google, y no requiere modificaciones en su parte (se utiliza el tipo de ID Token proporcionado por el proveedor, lo que permite implementar OpenPubKey solo a través de cambios en el lado del cliente de OpenID Connect).
El token emitido por el proveedor de OpenID se transforma en un certificado que vincula criptográficamente el identificador en OpenID Connect a la clave pública. Luego, el usuario utiliza la clave generada para firmar cualquier dato, y estas firmas pueden ser verificadas posteriormente en relación con el identificador en OpenID Connect. En OpenPubKey se utilizan claves efímeras, cuyo tiempo de vida es limitado; las claves se generan durante el inicio de sesión utilizando OpenID y se eliminan al finalizar la sesión con el proveedor de OpenID.
Algoritmo típico para crear una firma utilizando OpenPubKey:
- Inicio de sesión utilizando un proveedor de OpenID (Google, GitHub, Microsoft, etc.).
- Solicitud de un token de identificación al proveedor de OpenID.
- Devolución del token, firmado con la clave del proveedor e incluyendo un campo «nonce» con datos aleatorios enviados en la solicitud (se envía el hash SHA3 de la clave pública).
- Uso por parte del usuario del token recibido como certificado que incluye datos sobre la clave.
- Adjuntar el token a la firma, de manera similar a un certificado.
La verificación consiste en comprobar si el token adjunto ha sido firmado por el proveedor OpenID y verificar la validez de la firma digital en el recurso utilizando la clave pública, lo que permite confirmar que el recurso ha sido firmado con el identificador del certificado y que esta información ha sido validada por la firma del proveedor OpenID. Por ejemplo, el que crea la firma puede recibir un token firmado por el proveedor OpenID de Google con información que lo verifica como bob@gmail.com y utiliza la clave pública 0x54A5…FF. Luego, al recibir un mensaje firmado con la misma clave, puede utilizar el token firmado por el proveedor para verificar que la clave bob@gmail.com es 0x54A5…FF y que el mensaje fue efectivamente firmado por bob@gmail.com.
La simplificación de la arquitectura se ha logrado a través de ciertos compromisos (por ejemplo, la dependencia de proveedores externos OpenID y la falta de un registro de cambios con hash jerárquico), que son aceptables en algunas situaciones y no en otras. Para reducir la dependencia de los proveedores OpenID, cuya compromisión o acciones del personal pueden desacreditar el sistema (por ejemplo, un proveedor hackeado puede emitir una clave falsa a un tercero), se sugiere utilizar un eslabón adicional, aunque no obligatorio, MFA-Cosigner (Cosigner de Autenticación Multifactor), para la autenticación multifactor (el token debe estar firmado no solo por el proveedor principal, sino también por un servicio de autenticación independiente que confirme al usuario).
Entre las debilidades de OpenPubKey también se destaca la existencia de información externa que se puede utilizar para rastrear la actividad a lo largo del tiempo y de manera independiente de los cambios de nombre (reutilización de un token identificador en lugar de un nuevo certificado). La vinculación directa a las claves de OpenID Connect al verificar excluye la parte del servidor, pero complica significativamente la implementación del lado del cliente y deja más espacio para maniobras en el cliente (superficie de ataque), por ejemplo, debido a que el cliente asume la tarea de rotación de claves. La falta de un registro de cambios no permite al cliente rastrear posibles filtraciones de claves.
Fuente: opennet.ru
