Adquisición por fases de Sigstore – Linux.com

Esta publicación está escrita por Hayden Blauzvern y apareció originalmente en el blog de Sigstore. Sigstore es un nuevo estándar para firmar, verificar y proteger software. Es un proyecto de la Fundación Linux. Los desarrolladores, mantenedores de paquetes y empresas que deseen adoptar Sigstore pueden firmar artefactos ya publicados. Los firmantes pueden haber establecido procedimientos para almacenar y utilizar de forma segura las claves de firma. Sigstore se puede utilizar para firmar artefactos con claves de firma de larga duración autogestionadas existentes. Sigstore proporciona una experiencia de usuario simple para firmar, verificar y generar metadatos de firma estructurados para artefactos y firmas de contenedores. Sigstore también ofrece un registro de transparencia de uso gratuito e impulsado por la comunidad para verificar la creación de firmas. Sigstore también tiene la capacidad de usar certificados de firma de código con claves de firma de corta duración vinculadas a las identidades de OpenID Connect. Este enfoque de firma ofrece simplicidad debido a la falta de administración de claves; Sin embargo, esto puede ser un cambio demasiado drástico para las organizaciones que cuentan con una infraestructura de firma existente. Esta publicación de blog describe estrategias para facilitar la adopción de Sigstore mientras se utilizan los enfoques de firma existentes.

Firma con claves de larga duración autogestionadas

Los desarrolladores que administran sus propias claves de firma pero desean migrar a Sigstore pueden cambiar primero a Cosign para generar una firma sobre un artefacto. Cosign admite la importación de una clave PKCS#1 o PKCS#8 codificada con RSA, ECDSA o ED25519 PEM existente con cosign import-key-pair –key key.pem y se puede usar con cosign sign-blob –key cosign.key sign andcheck ruta del artefacto y cosigna clave de verificación de blob ruta del artefacto cosign.pub.

ventajas

Los desarrolladores pueden acostumbrarse a las herramientas de Sigstore para firmar y verificar artefactos. Las herramientas de Sigstore se pueden integrar en las canalizaciones de CI/CD. Para firmar contenedores, los metadatos de la firma se publican con la imagen OCI en un registro OCI.

Firma con claves autogestionables con verificabilidad

Si bien los desarrolladores administran sus propias claves de firma, pueden mejorar la verificabilidad de los eventos de firma mediante la publicación de firmas en el registro de transparencia de Sigstore, Rekor. Esto permite a los desarrolladores auditar cuándo se generan firmas para los artefactos que administran y también monitorear cuándo se usa su clave de firma para crear una firma. Los desarrolladores pueden cargar una firma en el registro de transparencia durante la firma con COSIGN_EXPERIMENTAL=1 cosign sign-blob –key cosign.key artifact-path . Si los desarrolladores quieren usar su propia infraestructura de firmas y aun así publicar en un protocolo de transparencia, los desarrolladores pueden usar la CLI o la API de Rekor. Para cargar un artefacto y verificar criptográficamente su inclusión en el registro mediante la CLI de Rekor: rekor-cli upload –rekor_server https://rekor.sigstore.dev –signature –public-key –artifact |local_path >rekor-cli verificar –rekor_server https://rekor.sigstore.dev –signature –public-key –artifact |local_path> Además de los certificados codificados con PEM y las claves públicas, Sigstore admite la carga de muchos formatos de clave diferentes, incluidos PGP, Minisign, SSH, PKCS#7 y TUF. Especifique el indicador de formato –pki al cargar mediante la CLI de Rekor. Por ejemplo, para cargar un artefacto firmado con una clave PGP: gpg –armor -u user@example.com –output signature.asc –detach-sig package.tar.gzgpg –export –armor «user@example.com» > public .keyrekor-cli upload –rekor_server https://rekor.sigstore.dev –signature signature.asc –public-key public.key –pki-format=pgp –artifact package.tar.gz

ventajas

Los desarrolladores comienzan a publicar eventos de firma para su verificación. Los consumidores de artefactos pueden crear una política de verificación que requiera que se publique una firma en un registro de transparencia.

Claves autoadministradas en certificado de firma de código basado en identidad con verificabilidad

Al solicitar un certificado de firma de código de la autoridad de certificación de Fulcio Sigstore, Fulcio vincula una identidad de OpenID Connect a una clave, lo que permite una política de verificación basada en la identidad en lugar de la clave. Los desarrolladores pueden solicitar un certificado de firma de código de Fulcio con una clave de larga duración autogestionada, firmar un artefacto con Cosign y cargar la firma del artefacto en el registro de transparencia. Sin embargo, los consumidores de artefactos aún pueden abrir con verificación (permitir el artefacto mientras se registra el error) si no quieren depender mucho de Sigstore (lo que requiere que los servicios de Sigstore se usen para la generación de firmas). Un desarrollador puede usar su clave autogestionada para generar una firma. Un verificador puede simplemente extraer la clave de verificación del certificado sin verificar la firma del certificado. (Tenga en cuenta que la verificación se puede realizar sin conexión, ya que la inclusión en un protocolo de transparencia se puede verificar mediante un paquete firmado permanentemente de Rekor y los certificados de firma de código se pueden verificar mediante el certificado raíz de CA. Vea un ejemplo de verificación de paquete de Rekor Véalo en el código de verificación de Cosign .) Una vez que un consumidor depende fuertemente de Sigstore, una canalización de CI/CD puede pasar al modo de cierre fallido (prohibir el artefacto si falla la verificación).

ventajas

Una política de verificación más estricta que obliga tanto a la presencia de la firma en un protocolo de transparencia como a la identidad del firmante. Las políticas de verificación se pueden hacer cumplir.

Firma basada en identidad («sin llave»)

Este último paso se agrega para completar. La firma se realiza mediante certificados de firma de código y las firmas deben publicarse en un registro de transparencia para su verificación. Con la firma basada en identidad, el cierre por falla es la única opción porque los servicios de Sigstore deben estar en línea para recuperar los certificados de firma de código y agregar entradas al registro de transparencia. Los desarrolladores ya no necesitan mantener claves de firma.

Conclusión

Las herramientas y la infraestructura de Sigstore se pueden utilizar como un todo o de forma modular. Cada integración separada puede ayudar a mejorar la seguridad de la distribución de artefactos al tiempo que permite actualizaciones incrementales y valida cada paso de la integración.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.