Quiero diseñar un sistema que dependa de ECDSA. Todos los mensajes se firman utilizando el algoritmo, y esto se usa para evitar la falsificación.
Sin embargo, si un usuario perdiera de alguna manera el control de su clave, se vería obligado a crear una nueva clave para firmar sus mensajes.
¿Existe algún mecanismo que pueda implementarse para hacer la transición de las personas a la nueva clave de firma de forma segura y automática? Además, ¿cómo se podría "revocar" la clave antigua?
Sí, pero hay consecuencias potencialmente de gran alcance. Voy a responder a tu pregunta de manera más general.
La respuesta simple es revocar la clave de firma. Tan fácil como esa respuesta es para una clave de usuario, todavía hay problemas. Por ejemplo, ¿todas las personas que podrían confiar en esa firma están suscritas y actualizadas en función de nuestra CRL? Si no, revocar la clave no tiene ningún efecto real.
Sin embargo, si tuviéramos que replantearlo un poco y hablar sobre una clave de firma de código o firma de certificado, el problema es mayor. Aún puede "simplemente" revocar la clave ... ¡pero el impacto es que todos los que hacen referencia a nuestra CRL ya no confiarán en nada firmado por esa clave de firma! Como puede imaginar, esto llevará a una cantidad significativa de trabajo para renunciar a todo.
La forma en que revoque la clave dependerá, por supuesto, del paquete específico que esté utilizando. Por lo general, implica llenar los datos sobre la clave comprometida en una lista de revocación de certificados que luego debe circular a todas las entidades de confianza.
¿Cómo se migran automáticamente a una nueva clave? Bueno, si han perdido el control de la clave, es difícil imaginar esto como un proceso automático; Realmente es más una reacción a un incidente. Sin embargo, para los cambios de clave normales, muchos productos manejan esto automáticamente (Servicios de Certificate Server de Microsoft con inscripción automática, por ejemplo, o con renovación de certificado de autoservicio) y con otros es bastante manual (PGP, OpenSSL), aunque ciertamente podría automatizarlo. un grado.
La dificultad de crear un sistema de este tipo desde cero es que, por lo general, preferirá -no- generar o almacenar la clave privada para el certificado, especialmente para un certificado de usuario; Realmente te gustaría que generaran la parte privada de la clave. Esto generalmente significa que deberán participar de alguna manera.
Tanto PGP como la SSL PKI global resuelven este problema de manera similar. Usted crea una clave super "confiable" con una larga caducidad que protege con fervor religioso; la clave se mantiene encriptada, escondida en un templo sagrado, solo vislumbrada por OSC debidamente ungidos, ese tipo de cosas. Es en quien confías. No lo usas.
Luego, con esa clave, usted firma su clave "Todos los días". Tiene una caducidad relativamente corta, pero sigue las mejores prácticas de seguridad. Aún así, va a donde se necesita ir.
Cuando alguna vez sospechas que la clave "todos los días" puede haber sido comprometida, la revocas y firmas una nueva con la clave del santo templo.
La revocación es tan simple como mantener una lista de claves revocadas (probablemente sus hashes) en una ubicación visible globalmente. Esa lista debe estar firmada. Cuando alguien verifica si confía en una clave, verifica la ruta de la firma de la clave hasta una raíz confiable. También verifican la lista de revocaciones.
El rendimiento de la verificación de la revocación de claves es un problema, pero si su infraestructura clave es pequeña, puede tener fácilmente una sola lista de revocación global que envíe a todos de forma regular.
Usando PGP, la respuesta es usar una subclave de firma, luego puede adjuntar la subclave a una llave maestra inutilizable ("stub") y usarla en el trabajo diario. Si esa clave se pierde, la clave de certificación se puede usar para designar una nueva subclave de firma; Sin embargo, el destinatario deberá actualizar la clave desde un servidor de claves.
Con X.509, no existe tal mecanismo.
Para ambos, puede mejorar la seguridad manteniendo la clave en una tarjeta inteligente, desde la cual no se puede exportar. La tarjeta inteligente OpenPGP ni siquiera tiene un comando para exportar una clave, mientras que las tarjetas inteligentes para usar con X.509 tienen un atributo "no exportable" en las claves que solo se pueden restablecer borrando la ranura de la clave.
Las tarjetas inteligentes están endurecidas contra los vectores de ataque comunes, como la radiación ionizante, el exceso / bajo voltaje y el exceso / bajo bloqueo, y requieren que el usuario presente el PIN correcto, lo que limita el número de intentos.
Para requisitos de seguridad aún más fuertes:
un lector de tarjetas inteligentes "Clase 2" tiene su propio teclado para ingresar el PIN de la tarjeta inteligente, por lo que no puede ser interceptado en la PC. Esto se puede utilizar con tarjetas inteligentes estándar.
un lector de tarjetas inteligentes "Clase 3" tiene su propio teclado para la entrada de PIN, y una pantalla alfanumérica controlada solo por la tarjeta, por lo que los datos a firmar se pueden mostrar antes de la entrada de PIN. Aquí, se necesita un código personalizado en la tarjeta inteligente, que representa un costo de desarrollo significativo.
Lea otras preguntas en las etiquetas key-management digital-signature