Gestión del Ciclo de Vida y Seguridad

Esta sección aborda los casos de uso administrativos y de seguridad que son fundamentales para garantizar la integridad, confiabilidad y sostenibilidad a largo plazo del ecosistema de la licencia de conducir digital. Estos procesos son gestionados por personal técnico y de seguridad de la OGTIC y del INTRANT.

Caso de Uso 1: Gestión del Esquema de la Credencial (Schema)

Este caso de uso se activa cuando los requisitos de negocio o legales de la licencia de conducir cambian (ej. se añade un campo nuevo como "Donante de Órganos").

Actor: Administrador de Credenciales (INTRANT), con aprobación de OGTIC. Trigger: Decisión administrativa o cambio en la normativa de tránsito. Mecanismo Técnico:

Definición de la Nueva Versión: Se crea una nueva versión del esquema JSON que define la estructura de la VC. Se le asigna un nuevo identificador de versión o URI.

JSON

// old_schema_uri: "https://intrant.gob.do/schemas/licencia/v1.0"
// new_schema_uri: "https://intrant.gob.do/schemas/licencia/v1.1"

Actualización del Portal de Emisión: El administrador actualiza la configuración en el portal Inji-Certify a través de una interfaz administrativa segura.

Llamada API (Interna): Se podría ejecutar una llamada PUT a un endpoint administrativo.

Endpoint: https://admin.inji-certify.intrant.gob.do/api/v1/schemas/driving-license Body (JSON):

JSON

{
  "schemaUri": "https://intrant.gob.do/schemas/licencia/v1.1",
  "schemaDefinition": { ... nuevo esquema JSON ... },
  "isActive": true
}

Plan de Transición:

Nuevas Emisiones: Todas las licencias emitidas o renovadas a partir de este punto utilizarán el nuevo esquema v1.1. Credenciales Antiguas: Las licencias existentes (v1.0) siguen siendo válidas hasta su fecha de expiración o hasta que sean renovadas. Las aplicaciones de los verificadores deben estar programadas para entender y validar ambas versiones del esquema. Impacto en el Ecosistema: Requiere coordinación para que las aplicaciones de verificadores se actualicen y puedan interpretar correctamente tanto el esquema antiguo como el nuevo.

Caso de Uso 2: Gestión de Claves Criptográficas del Emisor (INTRANT)

Este es uno de los procesos más críticos para la seguridad y confianza de todo el sistema.

Actor: Oficial de Seguridad (OGTIC/INTRANT). Trigger:

Rotación Programada: Política de seguridad que exige cambiar las claves cada 1-2 años. Compromiso de Clave: Sospecha o confirmación de que la clave privada ha sido expuesta. Mecanismo Técnico (Rotación Programada):

Generación de Nueva Clave: Se genera un nuevo par de claves (privada/pública) dentro del HSM. La nueva clave privada nunca sale del HSM.

Actualización del Documento DID: Se debe actualizar el documento DID del emisor (did:web:intrant.gob.do) para reflejar este cambio. El did.json se modifica para:

Añadir la nueva clave pública en la sección verificationMethod. Mantener la clave antigua en la misma sección, pero marcándola como histórica o expirada si es posible. Actualizar las secciones assertionMethod y authentication para que apunten a la nueva clave.

Llamada API (para publicar el did.json en el servidor web):

PUT /var/www/html/.well-known/did.json (Ejemplo de despliegue en servidor web)

Activación de la Nueva Clave: El portal Inji-Certify se configura para usar la nueva clave (key-2) para firmar todas las nuevas credenciales.

Mecanismo Técnico (Compromiso de Clave de Emergencia):

Revocación Inmediata: El Documento DID se actualiza inmediatamente para eliminar la clave comprometida de assertionMethod. Esto invalida su uso para nuevas firmas. Plan de Re-emisión: Se debe notificar a todos los ciudadanos que necesitan solicitar una re-emisión de su licencia, ya que las antiguas, aunque no expiradas, podrían no ser confiables. Actualización de Verificadores: Las aplicaciones de los verificadores deben forzar una actualización de la caché de la clave del INTRANT para asegurarse de que ya no confían en la clave comprometida. Impacto: Una rotación bien planificada es transparente para los usuarios. Un compromiso de clave es un incidente de seguridad grave que requiere una comunicación pública clara y una acción rápida de re-emisión.

Caso de Uso 3: Mantenimiento de la Lista de Estado de Credenciales

Garantiza que el mecanismo de revocación funcione de manera eficiente y escalable.

Actor: Administrador del Sistema (OGTIC). Trigger: La lista de estado actual (bitmap) se está llenando o ha alcanzado un tamaño que afecta el rendimiento. Mecanismo Técnico:

Creación de una Nueva Lista: Se genera una nueva lista de estado vacía.

Llamada API (Interna): POST https://api.intrant.gob.do/v1/statuslists Respuesta: Devuelve el ID y la URL de la nueva lista (ej. .../status/2). Configuración del Emisor: El portal Inji-Certify se configura para que todas las nuevas credenciales emitidas apunten a esta nueva lista en su propiedad credentialStatus. Archivado de la Lista Antigua: La lista antigua (.../status/1) se mantiene activa y disponible para que las credenciales ya emitidas que apuntan a ella puedan seguir siendo verificadas, pero ya no se le añaden nuevas revocaciones. Impacto: Es una tarea de mantenimiento rutinario y transparente para los usuarios finales, pero crucial para el rendimiento y la escalabilidad del sistema de revocación.

Caso de Uso 4: Monitoreo, Auditoría y Alertas del Sistema

Es el proceso continuo de vigilancia para asegurar la salud y seguridad del ecosistema.

Actor: Administrador del Sistema y Oficial de Seguridad (OGTIC). Trigger: Continuo (24/7). Mecanismo Técnico:

Recolección de Logs: Todos los componentes (servidores de API, HSM, portal de emisión, base de datos) envían sus logs a un sistema SIEM centralizado. Los logs deben incluir:

Intentos de acceso (exitosos y fallidos). Cada emisión de credencial (quién la autorizó, a quién, cuándo). Cada verificación de estado de revocación. Errores del sistema y métricas de rendimiento (latencia, tasa de errores). Creación de Paneles (Dashboards): Se configuran paneles en el SIEM o en herramientas como Grafana para visualizar en tiempo real:

Disponibilidad (Uptime) de las APIs críticas. Número de credenciales emitidas por día/hora. Latencia promedio de las verificaciones. Mapa de geolocalización de las solicitudes de verificación. Configuración de Alertas: Se definen reglas para generar alertas automáticas (vía email, Slack, PagerDuty) ante eventos anómalos.

Ejemplos de Alertas de Seguridad:

Múltiples intentos de inicio de sesión fallidos para un administrador. Emisión de credenciales fuera del horario laboral normal. Una tasa de error del 5% o más en la API de verificación. Un intento de acceso al HSM desde una IP no autorizada. Impacto: Permite la detección proactiva de problemas de rendimiento y brechas de seguridad, reduciendo el tiempo de respuesta ante incidentes. Genera un registro de auditoría inmutable crucial para investigaciones forenses.