Dentro de la Ceremonia de Llaves: PKI, HSM, el Proceso, las Personas y por qué es Importante

Publicado: agosto de 2025. Actualizado: agosto de 2026. Revisado por el equipo de asesoría de PKI y HSM de Encryption Consulting.

Cuando se habla de los fundamentos de la confianza digital, generalmente se hace referencia al cifrado , los certificados y la infraestructura de clave pública (PKI) . Casi nadie ha presenciado el proceso que realmente crea esa confianza: la ceremonia de entrega de claves, donde se genera la clave raíz de una autoridad de certificación, dentro de una bóveda, bajo grabación de vídeo, frente a testigos que firmarán un registro antes de marcharse.

Esta publicación profundiza en ese proceso. Cubre quién realiza una ceremonia de claves, cómo funcionan realmente el quórum M-of-N y el conocimiento dividido, dónde se ubica el límite FIPS del HSM , por qué una raíz fuera de línea y una CA emisora ​​en línea son ceremonias de diferente orden, cómo funcionan la copia de seguridad y el depósito en garantía del material de clave resultante, qué se debe verificar antes del día de la ceremonia y los modos de falla que convierten una ceremonia rutinaria en un hallazgo de auditoría.

¿Qué es una ceremonia de llaves y por qué es importante?

Una ceremonia de claves es el procedimiento formal y controlado mediante el cual se genera, activa y protege un par de claves criptográficas, generalmente para una autoridad de certificación (CA) , pero también para claves raíz empresariales, claves de firma de código u otro material criptográfico de alto valor. Combina a partes iguales un procedimiento técnico, un control de seguridad y un requisito de cumplimiento. Ya sea que la clave pertenezca a una CA raíz de confianza pública, un sistema nacional de identificación electrónica (eID) o la infraestructura de clave pública (PKI) interna de una empresa privada, la ceremonia tiene como objetivo brindar a todos los usuarios, auditores y a la propia organización, una garantía verificable de que la clave se generó bajo un control estricto y documentado.

Una ceremonia clave es importante por tres razones concretas:

• La transparencia genera confianza. El proceso se supervisa, se registra y se documenta para que los auditores externos y las partes que confían en él no tengan que fiarse de la palabra de la autoridad competente sobre cómo se creó la clave.
• La confianza distribuida reduce el riesgo. Los controles basados ​​en quórum implican que ninguna persona, por muy jerárquica que sea, puede generar, acceder o hacer un mal uso de la clave por sí sola.
• El cumplimiento normativo lo exige. WebTrust para autoridades de certificación, estándares ETSI y marcos como PCI DSS y eIDAS Todos exigen un proceso documentado y presenciado de generación de claves para las claves de CA.

Piénselo como el equivalente criptográfico de la acuñación de moneda: todo aquel que dependa de esa moneda necesita la garantía de que se produjo correctamente, de forma segura y bajo controles que puedan verificar posteriormente. Los Principios y Criterios de WebTrust para Autoridades de Certificación son el estándar de auditoría con el que se evalúan la mayoría de las CA de confianza pública, y las ceremonias de generación de claves son uno de los eventos más examinados.

¿Quiénes participan en una ceremonia de entrega de llaves?

Ninguna persona dirige una ceremonia clave, y esa es la clave. La separación de roles es el control, no una mera formalidad. Una ceremonia típica asigna:

• Administrador de la ceremonia. Es el propietario del guion, ejecuta cada paso en orden y es la única persona autorizada a desviarse de él, y solo haciendo una pausa y documentando el motivo.
• Responsables de criptomonedas / custodios de claves. Cada uno posee una parte del quórum, normalmente una tarjeta inteligente o una llave PED, y la presenta solo cuando el script lo requiere.
• Administrador de sistemas o HSM. Maneja las herramientas HSM y Security World bajo la dirección del administrador de la ceremonia.
• Testigos. Personal independiente (o, en el caso de ceremonias públicas de iniciación, un auditor externo) que supervisa cada paso, confirma que no se ha producido ningún desvío del protocolo y firma el registro.
• Escriba. Registra cada acción, marca de tiempo y participante en tiempo real; este registro constituye la evidencia de auditoría.
• Oyente. En el caso de las autoridades de certificación públicas auditadas por WebTrust o ETSI, un auditor independiente cualificado asiste y certifica por separado que la ceremonia se ajustó al guion aprobado.

Ningún rol puede completar una ceremonia por sí solo. Esto es intencional: un administrador de la ceremonia sin un testigo no tiene confirmación independiente de que se siguió el guion, y un oficial de criptografía sin quórum no puede desbloquear nada por sí mismo.

¿Qué son el quórum M-of-N, el conocimiento dividido y el control dual?

Estos tres principios, extraídos directamente de las directrices clave de gestión de la norma NIST SP 800-57 Parte 1 , son los que hacen que una ceremonia sea resistente tanto a la manipulación interna como al simple error humano.

1. Quórum M-de-N Esto significa que el HSM está configurado de manera que un subconjunto definido (M) de un grupo más amplio de custodios de claves (N) debe estar físicamente presente para autorizar una acción sensible. Un quórum de 3 de 5 implica que cinco personas poseen una tarjeta cada una, y tres de ellas, pero nunca menos, deben presentarlas juntas. Un umbral demasiado bajo debilita la seguridad; un umbral demasiado alto conlleva el riesgo de bloqueo operativo cuando los funcionarios están de viaje o no disponibles.
2. Conocimiento dividido Esto significa que ninguna persona posee información suficiente para reconstruir la clave por sí sola. La tarjeta o llave PED de cada custodio protege únicamente un fragmento del material de autorización, no la clave privada en sí misma en un formato que puedan extraer y utilizar de forma independiente.
3. Control dual Esto significa que al menos dos personas autorizadas deben actuar conjuntamente para realizar cualquier operación, generación, copia de seguridad o restauración sensible, de modo que una sola persona comprometida o coaccionada no puede actuar unilateralmente.

Estos tres principios explican por qué un portátil robado, un administrador coaccionado o un individuo malintencionado dentro de la organización no bastan para comprometer una ceremonia debidamente organizada. El quórum debe reunirse físicamente, y el registro documenta con exactitud quiénes lo hicieron.

¿Qué papel desempeña el HSM y dónde se sitúa el límite de FIPS?

El módulo de seguridad de hardware es donde se genera y se almacena la clave privada. Dentro del perímetro criptográfico a prueba de manipulaciones del HSM, definido y probado según la norma FIPS 140-3 , el material de la clave se crea mediante un generador de números aleatorios validado, se utiliza para firmar el certificado raíz y, posteriormente, permanece sellado dentro del módulo o sale únicamente como un archivo de copia de seguridad cifrado y protegido. La clave privada en texto plano nunca cruza ese perímetro. Si lo hiciera, se desmoronaría toda la premisa del proceso: que nadie pueda extraer ni hacer un uso indebido de la clave.

FIPS 140-3 es el estándar actual de EE. UU. y Canadá para la validación de módulos criptográficos, y reemplazó a FIPS 140-2. El cronograma de transición CMVP del NIST traslada todos los certificados FIPS 140-2 restantes a la lista histórica el 21 de septiembre de 2026, después de lo cual las nuevas adquisiciones federales requerirán módulos validados según 140-3. Para las ceremonias de claves de CA raíz e intermedias, el Nivel de Seguridad 3, que requiere autenticación de operador basada en identidad y detección de manipulación con respuesta, es el mínimo práctico que especifican la mayoría de las CA de confianza pública y las empresas reguladas; algunas implementaciones requieren la protección adicional del Nivel 4 contra ataques ambientales y no invasivos.

En la práctica, esto significa lo siguiente: antes de la ceremonia, confirme que la versión exacta del firmware del HSM y su certificado de validación FIPS cubren los algoritmos y tamaños de clave que planea generar. Una ceremonia que genere una clave en un firmware no validado o en un módulo que funcione en un modo no aprobado por FIPS puede invalidar el registro de auditoría, incluso si se siguieron correctamente todos los controles de procedimiento.

Autoridad de certificación raíz sin conexión frente a autoridad de certificación emisora ​​en línea: por qué la topología de despliegue cambia la ceremonia.

La mayoría de las jerarquías de infraestructura de clave pública (PKI) siguen la misma estructura: una CA raíz autofirmada en la cúspide, una o más CA intermedias (emisoras) debajo de ella, y certificados de entidad final emitidos por dichas CA intermedias. Esta estructura existe específicamente para minimizar la exposición de la raíz y determina directamente cómo se lleva a cabo la ceremonia de claves en cada capa.

Aspecto	CA raíz	CA Intermedio / Emisor
Estado de la red	Sin conexión, con aislamiento entre ceremonias.	En línea, conectado al software CA/RA
Localizacion fisica	Caja fuerte o bóveda cerrada con llave, apagada o sellada cuando no esté en uso.	Centro de datos seguro, en funcionamiento activo
Frecuencia de la ceremonia	Raro, normalmente una vez al crear la jerarquía, y luego solo para renovación o DR	Con mayor frecuencia, en el momento de la emisión, renovación o rotación.
Número típico de testigos	Máximo nivel: varios funcionarios, testigos independientes, a menudo un auditor externo.	Moderado: oficiales de criptografía más testigo interno
Consecuencia del compromiso	Catastrófico, toda la jerarquía debe ser revocada y reescrita.	Grave pero contenido, revocar y volver a emitir el intermedio afectado.

Dado que una raíz comprometida invalida todos los certificados emitidos bajo ella, las ceremonias de raíz reciben el máximo rigor que una jerarquía PKI puede ofrecer: espacio de bóveda dedicado, grabación de vídeo desde la apertura hasta el cierre de la bóveda, libros de registro notariados en los casos de máxima seguridad y múltiples testigos independientes. Las ceremonias de CA intermedias siguen un guion, quórum y control dual, pero su impacto operativo es menor porque una intermedia comprometida es un evento contenido y recuperable, en lugar de uno existencial.

Para obtener una guía paso a paso sobre una ceremonia de CA raíz pública, incluyendo cómo se verifica la autenticidad de la raíz a posteriori, consulte nuestro artículo del Centro de Educación sobre la ceremonia de clave de CA raíz.

¿Cómo se desarrolla realmente una ceremonia de entrega de llaves?

Las ceremonias clave nunca se improvisan. Cada ceremonia sigue un guion preescrito y aprobado, a veces llamado manual de instrucciones, por lo que nada se decide en la sala. La secuencia general es la siguiente:

1. Preparación. Se asignan los roles, se asegura la sala (videovigilancia, precintos de seguridad, acceso restringido) y se finaliza y aprueba con antelación el guion de la ceremonia.
2. Configuración del HSM y del entorno. El HSM y cualquier infraestructura de soporte, que en el caso de las implementaciones de Entrust nShield incluye el Sistema de Archivos Remotos (RFS) que almacena el Security World cifrado, se instalan, se refuerzan y se prueba su conectividad antes de que se manipule cualquier material clave.
3. Creación de dominio en Security World o equivalente. El operador del HSM inicializa el entorno protegido que contendrá las claves, definiendo el algoritmo, la seguridad de la clave y la política de quórum. Dicha configuración se almacena tanto en el HSM como encriptada en el RFS o equivalente.
4. Definición de quórum. El umbral M-de-N se establece y se registra en el script.
5. Personalización y distribución de tarjetas o llaves PED. Se crea una tarjeta para cada custodio, se protege con un PIN y se le entrega en presencia de un testigo; posteriormente, se registra y se almacena de forma segura cuando no está en uso.
6. Generación y certificación de claves. El par de claves raíz o intermedia se genera dentro del límite FIPS del HSM, y se crea el certificado correspondiente que, en el caso de la clave raíz, es autofirmado; en el caso de la clave intermedia, está firmado por la CA principal.
7. Documentación y aprobación. El registro en tiempo real del escriba, las firmas de los testigos y la grabación de vídeo se recopilan en el paquete de auditoría.
8. Sellado y almacenamiento. Las tarjetas se guardan en bolsas a prueba de manipulaciones en una caja fuerte, las copias de seguridad se cifran y se trasladan a una ubicación segura secundaria, y el HSM se sella o se apaga hasta la siguiente ceremonia programada.

Cada paso de esa secuencia existe porque omitirlo elimina pruebas que un auditor, o el abogado defensor de un atacante, solicitarían posteriormente.

¿Cómo se realiza el respaldo y el depósito en garantía del material clave?

Una ceremonia que genera una clave y nunca la respalda ha creado un único punto de fallo disfrazado de control de seguridad. La copia de seguridad se realiza dentro de la misma sesión presenciada y de doble control que la generación, no como una ocurrencia tardía:

• Exportación o clonación cifrada. El material clave se exporta en formato cifrado (nunca en texto plano) a un token de respaldo, un HSM clonado o un archivo de respaldo cifrado de Security World / RFS, según el proveedor.
• Compartir la custodia de la copia de seguridad. Los soportes de respaldo, así como las tarjetas o claves PED necesarias para restaurarlos, se distribuyen entre los responsables y se almacenan en ubicaciones geográficamente separadas y con acceso controlado, de modo que ninguna pérdida en un solo sitio destruya tanto la clave principal como su única copia.
• Depósito en garantía para entornos regulados. Algunos regímenes de cumplimiento y políticas de gestión de claves empresariales exigen una copia de custodia documentada que se mantenga bajo control conjunto (a menudo legal y de seguridad), con su propio registro de acceso separado de las operaciones diarias.
• Pruebas de restauración periódicas. Una copia de seguridad que nunca se ha restaurado es una hipótesis, no un plan de recuperación. Para conocer el aspecto operativo de las pruebas de copias de seguridad y conmutación por error de HSM bajo carga de producción, consulte nuestra publicación sobre Agrupación HSM y alta disponibilidad.

Los mismos principios de quórum M-de-N y de control dual que rigen la generación rigen la restauración. Un procedimiento de recuperación que solo requiere una persona para reactivar una clave raíz ha reintroducido silenciosamente el punto único de fallo que la ceremonia original pretendía eliminar.

¿Qué necesitas antes del día de la ceremonia? (Requisitos previos para la integración)

La mayoría de los problemas durante una ceremonia son, en realidad, problemas previos que surgen demasiado tarde para solucionarlos correctamente. Una lista de verificación de requisitos previos eficaz abarca cuatro áreas:

• Ambiente. Se ha asegurado la ubicación física, se ha confirmado el aislamiento de la red (las ceremonias raíz no deben tener ninguna ruta de red activa), y se han probado previamente los equipos de vídeo y grabación.
• Personal. Se han asignado todos los roles por nombre, se ha completado la verificación de identidad, se ha confirmado la disponibilidad del quórum para toda la sesión y se han identificado suplentes en caso de que un custodio designado no pueda asistir.
• Hardware. Se documentaron y confirmaron el modelo, el número de serie y la versión del firmware del HSM con el certificado de validación FIPS requerido; se inspeccionaron los sellos a prueba de manipulaciones; se realizó una prueba en seco en hardware que no es de producción para detectar errores de comando antes de que se registren.
• Documentación. El guion de la ceremonia, finalizado y aprobado con antelación; las páginas de registro en blanco, preparadas; los soportes, etiquetados y listos; y las líneas de aprobación lo suficientemente específicas como para registrar las ubicaciones de almacenamiento exactas y los números de serie, en lugar de simplemente "almacenado de forma segura".

Una regla que conviene tener presente: si no está en el guion, no sucedió, al menos desde la perspectiva del auditor. Escribir el guion a posteriori o improvisar un paso porque se omitió el ensayo general es la causa más común de irregularidades en ceremonias que, por lo demás, se llevaron a cabo correctamente.

¿Cómo se ve esto en la práctica?

Cuatro escenarios abarcan la mayoría de los motivos por los que las organizaciones realizan ceremonias:

• Generación de CA raíz pública. Una CA auditada por WebTrust genera una nueva clave raíz. Se requiere una bóveda dedicada, cinco o más participantes con los roles mencionados, un auditor independiente, documentación notariada y videovigilancia continua desde que se abre la bóveda hasta que se cierra.
• Puesta en marcha de CA intermedia empresarial. Un equipo interno de PKI pone en línea una nueva CA emisora ​​bajo una raíz offline existente. La ceremonia sigue estando guionizada y presenciada, pero la infraestructura es menor: normalmente participan dos responsables de criptografía, un testigo y un administrador de la ceremonia, y se lleva a cabo en un centro de datos seguro en lugar de una bóveda.
• Actualización o migración del firmware del HSM. El cambio a un nuevo hardware (por ejemplo, el restablecimiento de un Entrust nShield Security World en unidades actualizadas o la migración entre particiones Thales Luna) requiere volver a registrar a los clientes y volver a probar la conectividad antes de que se reanude cualquier operación con claves de producción, bajo los mismos controles de quórum utilizados en la generación original.
• Restauración tras un desastre. Tras un fallo de hardware o la pérdida del sitio, los responsables restablecen el quórum y restauran la clave raíz o intermedia desde su copia de seguridad cifrada en el hardware de reemplazo; se trata de un procedimiento de doble control ensayado, no improvisado.

¿Qué puede salir mal y cómo se puede prevenir?

La mayoría de los problemas que se presentan en las auditorías o revisiones de incidentes ocurren durante las ceremonias, y existen tres modos de falla principales:

• Desviación del guion. Se omite, se reordena o se improvisa un paso porque no se realizó la prueba en seco o el script no era lo suficientemente detallado para cubrir un caso excepcional. Solución: una prueba en seco obligatoria en hardware que no sea de producción, un script bloqueado y preaprobado, y una regla que establece que cualquier desviación se detenga, se documente y se vuelva a aprobar antes de continuar, en lugar de pasar desapercibida.
• Detección de deficiencias en testigos o auditorías. Un testigo se ausenta, aunque sea brevemente, y esa interrupción en la atestación continua se convierte en un hallazgo posterior, o bien el registro en tiempo real se reconstruye a partir de la memoria a posteriori en lugar de escribirse en directo. Medidas de mitigación: cobertura continua de testigos con sustituciones documentadas si alguien debe ausentarse, registro en directo de cada acción y grabación de vídeo como respaldo del registro escrito.
• Fallo del HSM en plena ceremonia. Si se producen fallos de hardware antes de que finalice la copia de seguridad, el equipo debe decidir si reiniciarla y desde dónde. Medidas de mitigación: verificar que la copia de seguridad cifrada se complete y valide antes de declarar la sesión cerrada, disponer de un HSM validado de repuesto para procedimientos críticos y programar el procedimiento de cancelación/reanudación con antelación en lugar de decidirlo en directo.

Todos estos problemas se pueden evitar con una planificación previa, realizada antes de que se cierre la sala, y no durante la ceremonia en sí.

¿Qué tipo de ceremonia necesitas?

Tipo de ceremonia	Caso de uso típico	Rigor / testigos	Frecuencia
Generación de claves de CA raíz	Establecer una nueva base de confianza, pública o empresarial.	Máximo: 5 o más participantes, a menudo un auditor externo, vídeo, archivo físico.	Una vez creada la jerarquía, entonces rara vez
Generación de claves de CA intermedia/emisora	Establecer una nueva CA subordinada bajo una raíz existente	Moderado: oficiales de criptografía más testigo interno	Cada pocos años, o según un nuevo CA
Rotación/renovación de llaves	Sustitución de una clave antes de la expiración del certificado	Moderado, sigue el guion original aprobado.	Programado según la política del certificado
Restauración tras un desastre	Reconstrucción de una CA o HSM después de una falla de hardware o pérdida del sitio.	Alto: restauración de control dual desde copia de seguridad cifrada	Según sea necesario; ensayado periódicamente
Desactivación de HSM / Destrucción de claves	Retirar hardware o destruir una clave comprometida o caducada.	Alto: se presenció la puesta a cero y la aprobación de la auditoría.	Fin del ciclo de vida del hardware o de la llave.

Limitaciones

Esta publicación describe las prácticas de ceremonia de claves generalmente aceptadas a nivel profesional, y no sustituye la Política de Certificados/Declaración de Prácticas de Certificación (CP/CPS) aprobada por su organización, la documentación oficial de la ceremonia de un proveedor específico de HSM ni los requisitos auditados que una CA de confianza pública debe cumplir según WebTrust o ETSI. La estructura exacta del script, la mecánica de las tarjetas y la terminología (Security World y RFS para Entrust nShield; particiones autenticadas con PED frente a particiones autenticadas con contraseña para Thales Luna; flujos de trabajo de la consola de HSM en la nube para AWS CloudHSM, Azure Managed HSM o Google Cloud HSM) varían según el proveedor y el modelo de implementación, y los requisitos regulatorios aplicables varían según la jurisdicción y el sector. Considere esto como el marco de referencia para la planificación y, a continuación, valide los detalles con su CPS y la documentación actual de su proveedor de HSM antes del día de la ceremonia.

¿Qué recomendaría Encryption Consulting?

Realizar una ceremonia de entrega de claves correctamente requiere más que reunir a personas en una sala segura y generar claves. Requiere procedimientos validados, una estricta separación de roles y documentación diseñada para superar cualquier auditoría años después. Nuestros equipos de Servicios PKI y Servicios HSM brindan soporte integral para las ceremonias.

• Diseño del procedimiento de la ceremonia. Scripts paso a paso creados según sus requisitos de cumplimiento, WebTrust, PCI DSS, FIPS 140-2/3y el propio CP/CPS de su organización.
• Documentación completa. Elabore libros, listas de verificación previas a la ceremonia, guiones para la ceremonia e informes posteriores a la ceremonia que resistan una auditoría.
• Soporte de firmware y configuración. Actualizaciones del firmware del HSM, inicialización del hardware y configuración de Security World o de la partición, para que la ceremonia comience sobre bases validadas.
• Ejecución y facilitación de la ceremonia. Podemos actuar como administradores de la ceremonia, custodios o testigos independientes, velando por el quórum y registrando cada acción.
• Formación y transferencia de conocimientos. Capacitamos a su equipo interno para que puedan organizar futuras ceremonias con confianza y de forma autónoma.
• Garantía posterior a la ceremonia. Documentación finalizada, validación de auditoría y recomendaciones para la gestión continua de claves y las pruebas de respaldo.

Para las organizaciones que desean una protección de claves de nivel de hardware sin poseer ni operar ellas mismas la infraestructura HSM, HSM-as-a-Service pone la capacidad HSM validada y de alta disponibilidad bajo el mismo rigor descrito aquí, sin la carga de adquirir y mantener el hardware.

Preguntas frecuentes

¿Cuánto tiempo dura una ceremonia de entrega de llaves?
Una ceremonia de CA raíz suele durar un día completo, incluyendo la configuración, la verificación, la generación, la copia de seguridad, la documentación y el sellado. Las ceremonias de CA intermedias suelen ser más cortas, a menudo de unas pocas horas, ya que los requisitos de seguridad física y de testigos son menores.

¿Quiénes deberían estar presentes en la sala durante una ceremonia importante?
Como mínimo, se requiere un administrador de la ceremonia, los responsables de criptografía que poseen acciones de quórum, un operador de HSM y al menos un testigo independiente. Las ceremonias raíz de confianza pública suelen incluir un auditor externo y testigos adicionales para cumplir con los requisitos de WebTrust o ETSI.

¿Cuál es la diferencia real entre una ceremonia de CA raíz y una ceremonia de CA intermedia?
La vulneración del certificado raíz es catastrófica y afecta a todos los certificados emitidos por la jerarquía, por lo que las ceremonias de certificación raíz reciben el máximo rigor: bóvedas sin conexión, más testigos, grabación de vídeo y, a menudo, certificación notarial. Las ceremonias intermedias siguen utilizando el quórum y el control dual, pero reducen la seguridad física, ya que un certificado intermedio comprometido se encuentra contenido y es recuperable.

¿Es posible celebrar una ceremonia de entrega de llaves de forma remota?
Algunas organizaciones realizan ceremonias de menor riesgo, como la rotación de una clave intermedia interna, con participantes remotos bajo control de video y uso compartido de pantalla. Las ceremonias de la CA raíz para jerarquías de confianza pública casi siempre se realizan de forma presencial, ya que la participación remota debilita la evidencia física de la cadena de custodia que exigen los auditores.

¿Qué ocurre si el HSM falla durante la ceremonia?
Una ceremonia bien planificada prevé esto de antemano: el script especifica si se debe abortar y reiniciar desde el último paso completado o continuar con un HSM de repuesto validado, y ninguna copia de seguridad se considera completa, y la sesión no se cierra, hasta que se haya generado y verificado la copia de seguridad cifrada.

Conclusión

Una ceremonia de claves es uno de los eventos más importantes en el ciclo de vida de una PKI. Combina la separación de roles, el quórum M-of-N, el conocimiento dividido y el límite validado por FIPS de un HSM en un procedimiento único y auditable que brinda a todos los involucrados (auditores, partes confiables y la propia organización) una respuesta verificable a la pregunta "¿cómo sabemos que esta clave es confiable?". Si se define correctamente la topología (raíz fuera de línea, intermedios en línea), se planifica cada paso con anticipación, se realiza una copia de seguridad bajo el mismo control dual utilizado para generar la clave y se ensayan los modos de falla antes de que se presenten inesperadamente, la ceremonia cumple exactamente con su propósito: crear una raíz de confianza que nadie tenga que aceptar por fe.

Con la orientación experta de un socio que ha llevado a cabo este proceso en jerarquías públicas y empresariales, no tiene que planificar su primera ni su quincuagésima ceremonia en solitario.

Referencias

• Principios y criterios de WebTrust para las autoridades de certificaciónContador Público Certificado Canadá
• Requisitos básicos del Foro CA/Browser para la emisión y gestión de certificados TLS de confianza pública
• NIST SP 800-57 Parte 1 Revisión 5, Recomendación para la gestión de claves
• FIPS 140-3, Requisitos de seguridad para módulos criptográficos, NIST
• Esfuerzo de transición de FIPS 140-3, NIST CSRC
• Conjuntos de tarjetas de operador (OCS)Documentación de Entrust nShield