La Fundaci\u00f3n Linux, BastionZero y Docker han presentado un nuevo proyecto de c\u00f3digo abierto llamado OpenPubKey, que desarrolla el protocolo criptogr\u00e1fico hom\u00f3nimo para certificar digitalmente diversos objetos. La tecnolog\u00eda ha sido creada como un proyecto conjunto de BastionZero y Docker con el objetivo de simplificar la certificaci\u00f3n digital de las im\u00e1genes de contenedores Docker para evitar su suplantaci\u00f3n y confirmar la construcci\u00f3n por parte del creador declarado. El proyecto se desarrollar\u00e1 en una plataforma neutral bajo la tutela de la Fundaci\u00f3n Linux, lo que eliminar\u00e1 la dependencia de empresas comerciales individuales y facilitar\u00e1 la colaboraci\u00f3n con participantes externos. La implementaci\u00f3n de referencia de OpenPubKey est\u00e1 escrita en Go y se distribuye bajo la licencia Apache 2.0. <\/p>\n
Las capacidades de OpenPubKey no se limitan solo a las im\u00e1genes de contenedores; la tecnolog\u00eda puede aplicarse para confirmar la fuente de obtenci\u00f3n de cualquier recurso, prevenir la suplantaci\u00f3n de dependencias y aumentar la seguridad de los canales de distribuci\u00f3n de conjuntos de datos. Por ejemplo, la tecnolog\u00eda 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\u00f3n con el identificador OpenID declarado. <\/p>\n
Por su prop\u00f3sito, OpenPubKey es similar a la sistema Sigstore creado en Google y previamente transferido a la Fundaci\u00f3n Linux, pero se diferencia de este por su notable simplificaci\u00f3n en la implementaci\u00f3n, uso y mantenimiento al eliminar componentes de servidor centralizados responsables de mantener un registro p\u00fablico que confirme la autenticidad de los cambios (transparency log) y facilitar el funcionamiento de las autoridades certificadoras (Certificate Authority). <\/p>\n
En lugar de implementar sus propias autoridades certificadoras, OpenPubKey utiliza la autenticaci\u00f3n mediante la tecnolog\u00eda OpenID y vincula las firmas generadas a los proveedores existentes de OpenID Connect. En otras palabras, OpenPubKey permite asociar claves criptogr\u00e1ficas a usuarios espec\u00edficos utilizando proveedores de OpenID Connect (IdP) en lugar de autoridades certificadoras. La tecnolog\u00eda 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\u00e9s de cambios en el lado del cliente de OpenID Connect). <\/p>\n
El token OpenID emitido por el proveedor se transforma en un certificado que vincula criptogr\u00e1ficamente el identificador en OpenID Connect a una clave p\u00fablica. Luego, el usuario utiliza la clave generada para firmar cualquier dato, y estas firmas pueden ser verificadas posteriormente en relaci\u00f3n con el identificador en OpenID Connect. En OpenPubKey se utilizan claves ef\u00edmeras, cuya duraci\u00f3n est\u00e1 limitada \u2014 las claves se generan al iniciar sesi\u00f3n con OpenID y se eliminan al finalizar la sesi\u00f3n con el proveedor de OpenID. <\/p>\n
Algoritmo t\u00edpico para crear una firma utilizando OpenPubKey: <\/p>\n
La verificaci\u00f3n se reduce a comprobar si el token adjunto ha sido firmado por el proveedor de OpenID y a verificar la validez de la firma digital en el recurso mediante la clave p\u00fablica, lo que permite confirmar que el recurso ha sido firmado usando el identificador del certificado y esto est\u00e1 corroborado por la firma del proveedor de OpenID. Por ejemplo, el firmante puede recibir un token firmado por el proveedor de OpenID de Google con informaci\u00f3n que lo verifica como bob@gmail.com, y usa la clave p\u00fablica 0x54A5\u2026FF. Luego, al recibir un mensaje firmado con la misma clave, el receptor puede usar el token firmado por el proveedor para verificar que la clave bob@gmail.com \u2014 0x54A5\u2026FF y el mensaje hayan sido efectivamente firmados por bob@gmail.com. <\/p>\n
La simplificaci\u00f3n de la arquitectura se ha logrado mediante ciertos compromisos (por ejemplo, la dependencia de proveedores externos de OpenID y la falta de registro de cambios con hashing jer\u00e1rquico), que son aceptables en algunas situaciones y no en otras. Para reducir la dependencia de los proveedores de OpenID, cuya compromisi\u00f3n 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 enlace adicional, aunque no obligatorio, MFA-Cosigner (Co-firmante de Autenticaci\u00f3n Multifactor) para la autenticaci\u00f3n multifactor (el token debe ser firmado no solo por el proveedor principal, sino tambi\u00e9n por un servicio de autenticaci\u00f3n independiente que confirme al usuario). <\/p>\n