Firma de código usando Google Cloud KMS
Con el servicio Google Cloud KMS, obtienen un HSM en la nube con certificación FIPS 140-2 Level 3. Pueden firmar código de forma segura, rápida y desde cualquier lugar. Además, los costos por número de operaciones (firmas) son muy favorables. Cloud KMS es compatible con la firma usando Microsoft Cryptography API: Next Generation (CNG).
Para configurar y firmar el código es necesario realizar los siguientes pasos, que repasaremos uno a uno:
- Instalar el proveedor CNG
- Crear Key Ring y clave privada
- Crear CSR y obtener certificado
- Firmar su artefacto
Descargar el proveedor CNG y los paquetes necesarios
Google ha publicado su proveedor CNG en su repositorio en GitHub. Estos archivos se pueden instalar en su sistema Windows usando el archivo de instalación .msi adjunto. Este programa necesita configuración en forma de un archivo YAML, que encontrará en uno de los pasos de esta guía.
Ahora cambie a Linux (puede utilizar WSL en Windows). Se recomienda crear la clave privada y CSR en Linux; aunque en Windows puede instalar OpenSSL en PowerShell, en Linux es menos probable que se encuentre con complicaciones. Este es también el enfoque recomendado por la guía oficial de Google.
Para la comunicación con la nube usaremos la aplicación gcloud del paquete google-cloud-cli.
Crear Key Ring y clave privada en Cloud HSM
Realice los siguientes pasos en Linux. Cree un nuevo conjunto de claves (Key Ring) para el API del Cloud Key Management Service (KMS) y dentro de él, cree una clave privada que esté protegida por hardware mediante Cloud HSM. Seleccione el algoritmo RSA asimétrico para la firma y una longitud de clave de 3072b, porque SignTool no puede usar claves EC en combinación con Google Cloud KMS CNG.
Primero, inicie sesión en su cuenta de Google y autorice la sesión en Linux (también se aplica para Windows PowerShell):
gcloud auth application-default login
Así es como se crea un Key Ring para colocar la clave privada:
gcloud kms keyrings create KEYRING-NAME \
--location=europe-west3 \
--project=PROJECT-NAME
Colocaremos una clave privada en este Key Ring. La generaremos también mediante la utilidad gcloud; complete los nombres (con mayúsculas) según la realidad (nombre del proyecto en GCP) y su propia denominación.
gcloud kms keys create KEY-NAME --keyring=KEYRING-NAME --location=europe-west3 --purpose=asymmetric-signing --protection-level=hsm --default-algorithm=rsa-sign-pkcs1-3072-sha256 --project=PROJECT-NAME
Una vez que cree la primera versión de la clave, le recomendamos que en su detalle en Cloud Console copie el Copy resource name, ya que necesitará este dato para el KEY_ID. Se ve así: projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1
Ahora de vuelta en Windows, será necesario crear un archivo config.yaml con la configuración para la integración KMS. Ingrese lo siguiente en powershell:
$yaml = @"
resources:
- crypto_key_version: "projects/PROJECT-NAME/locations/europe-west3/keyRings/KEYRING-NAME/cryptoKeys/KEY-NAME/cryptoKeyVersions/1"
"@
$yaml = $yaml -replace "`t"," "
$utf8NoBom = New-Object System.Text.UTF8Encoding($false)
[System.IO.File]::WriteAllText('C:\Windows\KMSCNG\config.yaml', $yaml, $utf8NoBom)
Crear CSR
Naturalmente, no es posible importar un certificado con clave privada en el HSM, al igual que no es posible exportar este par. Por lo tanto, la clave privada y CSR deben generarse en el HSM, y luego debe enviarse a SSLmarket y firmarse por DigiCert. La importación del certificado emitido es el siguiente paso.
Lo mejor es crear CSR en Linux, utilizando las bibliotecas libengine-pkcs11-openssl, libkmsp11 y API. Por supuesto, también necesitará el paquete google-cloud-cli.
Así es como se ve la creación de CSR (complete el nombre de la clave (CryptoKey) de acuerdo con GCP después de pkcs11:object=):
openssl req -new \
-subj "/C=CZ/O=ZONER /CN=ZONER" \
-sha256 -engine pkcs11 -keyform engine \
-key "pkcs11:object=KEY_NAME;type=private" \
-reqexts v3_req -config <(cat /etc/ssl/openssl.cnf; printf "\n[v3_req]\nextendedKeyUsage=codeSigning\n") \
-out cs-request.csr
La solicitud para DigiCert luego estará en el archivo cs-request.csr en la carpeta donde está trabajando. Envíenos este CSR.
Obtener el certificado
Haga que DigiCert firme la CSR creada y recibirá un nuevo certificado de firma de código. Ya no necesita insertar esto en Google Cloud Console, basta con tener la clave privada allí. Trabajaremos con el certificado localmente en Windows, guárdelo en algún lugar del disco como un archivo.
Firme sus artefactos
Proseguimos en Windows. A partir del año 2024, Google ha lanzado oficialmente el proveedor Cloud KMS CNG, que se registra en Windows como Crypto Service Provider (CSP) / Key Storage Provider (KSP) con el nombre Google Cloud KMS Provider. Gracias a esto, SignTool puede usar claves en la nube y no solo localmente en el token.
Firmaremos usando SignTool del SDK de Windows y la versión x64 de la herramienta; recomendamos la versión más reciente. Asegúrese de ingresar los parámetros correctos (ver explicación debajo del ejemplo).
Ejemplo de firma con SignTool y PowerShell:
& $SignTool sign `
/v /debug `
/fd sha256 /td sha256 `
/tr http://timestamp.digicert.com `
/f "PATH_TO_CERT" `
/csp "Google Cloud KMS Provider" `
/kc "projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1" `
"PATH_TO_FILE_TO_SIGN"
Explicación:
- /f PATH_TO_CERT es la ruta al archivo con el certificado de firma de código (parte pública). Así combinará recibirlo de nosotros, si lo hace emitir para HSM.
- /csp especifica el proveedor CNG específico, ya que puede haber varios en Windows. Google Cloud KMS Provider se registra igual que, por ejemplo, “Microsoft Software Key Storage Provider”.
- /kc (Key Container) es la ruta a la clave específica y su versión (KMS CryptoKeyVersion), corresponde al mencionado KEY_ID.
Durante la firma, verá qué certificado se seleccionó para la firma y el resultado. Como SignTool tiene un problema con la vinculación del certificado a la clave privada en la nube (a través de CSP/KSP), recomiendo tener el certificado almacenado localmente en un archivo. La elección por el nombre de la organización o el hash SHA1 del certificado es problemática y generalmente no funciona; solo funcionó el certificado en el archivo.
The following certificate was selected:
Issued to: ZONER a.s.
Issued by: DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
Expires: Wed Nov 12 01:59:59 2025
SHA1 hash: F9BC96AC1764AD9F2072780FFB64940538A3B292
The following additional certificates will be attached:
Issued to: DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
Issued by: DigiCert Trusted Root G4
Expires: Tue Apr 29 01:59:59 2036
SHA1 hash: 7B0F360B775F76C94A12CA48445AA2D2A875701C
Done Adding Additional Store
Successfully signed: C:\Users\jindrich.zechmeister\HelloSign.exe
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
Adicional - verificación de la firma
Podemos verificar también la firma digital recién creada con SignTool.
PS C:\Users\jindrich.zechmeister> signtool verify /pa c:\Users\jindrich.zechmeister\App.exe
File: c:\Users\jindrich.zechmeister\App.exe
Index Algorithm Timestamp
========================================
0 sha256 RFC3161
Successfully verified: c:\Users\jindrich.zechmeister\App.exe
El archivo EXE firmado se ha firmado con éxito.
Fuentes:
- artículo You can now sign Microsoft Windows artifacts with keys protected by Cloud HSM, disponible en Blog de Google Cloud.
- GCP Docs: Provider for Microsoft Cryptography API: Next Generation (CNG)
- GCP Docs: Use CNG Provider and SignTool to sign Windows artifacts
Lo sentimos que no haya encontrado lo necesario aquí.
Ayúdanos mejorar el artículo, por favor. Escríbenos lo que esperaba aquí y no encontró.