Linux Foundation, BastionZero y Docker han presentado OpenPubKey, un nuevo proyecto de código abierto que desarrolla el protocolo criptográfico homónimo para la firma digital de objetos arbitrarios. Esta tecnología, desarrollada conjuntamente por BastionZero y Docker, simplifica la firma digital de imágenes de contenedores Docker, previniendo así la manipulación y verificando que fueron creadas por su autor original. El proyecto se desarrollará en una plataforma neutral bajo el amparo de la organización. Linux La fundación elimina la dependencia de empresas comerciales individuales y simplifica la colaboración con colaboradores 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 a imágenes de contenedores y la tecnología se puede utilizar para confirmar el origen de cualquier recurso, evitar la sustitución de dependencias y mejorar la seguridad de los canales de distribución de conjuntos de datos. Por ejemplo, la tecnología es aplicable para verificar ensamblajes de programas, mensajes individuales y confirmaciones. Los creadores de firmas solo necesitan tener una cuenta en un servicio que admita OpenID, y los consumidores tienen la oportunidad de verificar las firmas adjuntas y confirmar su conexión con el identificador OpenID declarado.
En su propósito, OpenPubKey es similar al creado por Google y transferido previamente a Linux Foundation es similar al sistema Sigstore, pero se diferencia de él en que simplifica significativamente la implementación, el uso y el mantenimiento al eliminar los componentes de servidor centralizados responsables de mantener un registro público que confirme la autenticidad de los cambios (registro de transparencia) y garantice el funcionamiento de las autoridades de certificación (Autoridad de Certificación).
En lugar de implementar sus propias autoridades de certificación, OpenPubKey utiliza la tecnología de autenticación OpenID y vincula las firmas creadas con los proveedores de OpenID Connect existentes. En otras palabras, OpenPubkey le permite vincular claves criptográficas a usuarios específicos utilizando proveedores de OpenID Connect (IdP) en lugar de autoridades de certificación. La tecnología es totalmente compatible con los proveedores de OpenID existentes, como GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak y Google, y no requiere cambios por su parte (se utiliza el token de identificación estándar proporcionado por el proveedor, que le permite implementar OpenPubKey solo a través de cambios en el lado del cliente OpenID Connect).
El token emitido por el proveedor 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 se pueden verificar posteriormente con el identificador en OpenID Connect. OpenPubKey utiliza claves efímeras que tienen una vida útil limitada: las claves se generan durante el inicio de sesión de OpenID y se eliminan cuando finaliza la sesión con el proveedor de OpenID.
Un algoritmo de ejemplo para crear una firma usando OpenPubKey:
- Inicie sesión utilizando un proveedor de OpenID (Google, GitHub, Microsoft, etc.).
- Solicite un token de identificación al proveedor de OpenID.
- Devolver un token firmado por la clave del proveedor e incluir un campo “nonce” con datos arbitrarios transmitidos durante la solicitud (se transmite el hash SHA3 de la clave pública).
- Utilice en el lado del usuario el token recibido como certificado, incluidos los datos clave.
- Adjuntar un token a una firma, similar a un certificado.
La verificación consiste en comprobar si el token adjunto está firmado por el proveedor de OpenID y la exactitud de la firma digital del recurso mediante la clave pública. Esto permite garantizar que el recurso esté firmado con el identificador del certificado y que la firma del proveedor de OpenID lo confirme. Por ejemplo, el creador de la firma puede recibir un token firmado por el proveedor de OpenID de Google con información de que está verificado como bob@gmail.com y utiliza la clave pública 0x54A5…FF. Al recibir un mensaje firmado con la misma clave, el destinatario puede usar el token firmado por el proveedor para verificar que la clave bob@gmail.com sea 0x54A5…FF y que el mensaje esté firmado por bob@gmail.com.
La simplificación de la arquitectura se logra mediante ciertos compromisos (por ejemplo, la dependencia de proveedores externos de OpenID y la ausencia de un registro de cambios con hash jerárquico), que son aceptables en algunas situaciones, pero no en otras. Para reducir la dependencia de los proveedores de OpenID, cuyo compromiso o acciones de cuyo personal pueden desacreditar el sistema (por ejemplo, los proveedores pirateados pueden emitir una clave ficticia a un tercero), se propone utilizar un MFA-Cosigner adicional, pero no obligatorio. Enlace (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 confirma al usuario).
Una de las debilidades de OpenPubKey es también la presencia de información extraña que puede usarse para rastrear la actividad durante mucho tiempo e independientemente del cambio de nombre (reutilizar un token de identificación en lugar de un nuevo certificado). La vinculación directa a las claves OpenID Connect durante la verificación elimina la parte del servidor, pero complica significativamente la implementación en el lado del cliente y deja más margen de maniobra al realizar ataques (superficie de ataque) en el cliente, por ejemplo, debido al hecho de que la tarea de La rotación de claves recae en el cliente. La ausencia de un registro de cambios no permite al cliente rastrear posibles filtraciones de claves.
Fuente: opennet.ru
