PKI y firmas con claves protegidas.

El HSM protege una clave de firma dentro del límite previsto; no decide por sí mismo si debe aprobarse un paquete de software. Por eso vinculamos las llamadas de firma a aplicaciones identificadas, permisos y aprobaciones. En la firma de código, el artefacto y la aprobación quedan unidos entre sí para que los cambios posteriores sean detectables. El software de CA y el proveedor criptográfico del HSM deben admitir ambos el algoritmo utilizado y el acceso a la clave. Los almacenes de confianza (trust stores), la comprobación del estado y la renovación se prueban con contrapartes representativas.

Una tarjeta de administrador perdida, certificados caducados y una CA emisora comprometida son eventos distintos. Elaboramos los procedimientos adecuados y probamos el procedimiento de recuperación acordado. La aceptación documenta, entre otras cosas, la emisión, la renovación, la revocación y las solicitudes incorrectas. Los perfiles de certificado, las clases de dispositivo y las relaciones de confianza existentes ayudan a planificar una operación en paralelo durante la migración.

Comprobamos la conexión compatible con cada producto, por ejemplo a través de un CNG Key Storage Provider, PKCS #11 o un proveedor Java. Un mismo nombre de algoritmo no garantiza por sí solo la compatibilidad: los mecanismos, los atributos de clave, el padding y la versión del proveedor también deben coincidir. Para las entidades de certificación existentes se aclara si es posible una transferencia de claves admisible o si se necesita una nueva CA con una fase de transición. La confianza de los sistemas conectados se tiene en cuenta de forma explícita en la prueba.

El pipeline no debería disponer de forma permanente de una clave de producción de libre uso. Separamos la compilación de la aprobación de la firma, vinculamos los trabajos de firma a un sistema identificado y determinamos qué artefactos pueden firmarse con qué clave. El sello de tiempo, la evidencia del hash del artefacto y el registro se planifican conforme al formato de firma. El HSM es aquí un componente de protección: la revisión del código y la decisión sobre una publicación siguen siendo tareas del proceso de desarrollo y aprobación.

Una organización ya utiliza certificados para dispositivos, usuarios y servicios internos. OTOKO® recopila los perfiles de certificado, la distribución y las cadenas de confianza, y pone a prueba la conexión prevista con el HSM primero fuera del entorno de producción. Después planificamos la migración, incluida la renovación, la información de revocación y los límites de vuelta atrás. Antes del traspaso se comprueban contrapartes concretas: un certificado emitido solo es un éxito cuando el inicio de sesión, el acceso al servicio o la verificación de la firma funcionan en el sistema previsto.