Summary

  • El borrador de arquitectura KEYTRANS del 1 de noviembre añade una sección sobre integridad del cliente que faltaba en la versión del 7 de octubre.
  • Si el operador reparte software o parámetros manipulados a una persona, puede apagar la comprobación de pruebas o cambiar las claves que esa persona usa para confiar en el registro.

La promesa de la transparencia de claves es bastante fácil de explicar: si un servicio asigna a escondidas otra clave pública a una cuenta, el registro y sus pruebas deberían dejar rastro. La revisión 11 del borrador KEYTRANS formula una pregunta menos cómoda. ¿Qué pasa si el mismo servicio distribuye la aplicación encargada de mirar ese rastro?

La nueva sección 7.3 sitúa allí la dependencia. El operador suele repartir tanto el programa como la configuración del registro. Con una versión modificada para una persona, podría desactivar la verificación de pruebas o la vigilancia continua. También podría sustituir la clave pública del registro o de un tercero por una bajo su control. El resto de los usuarios puede seguir viendo un registro coherente. La comprobación que falla es la de quien recibió otro cliente.

La revisión 10, fechada el 7 de octubre, no tenía una sección de integridad del cliente. La nueva enumera cuatro supuestos: ejecución segura en el dispositivo, implementación correcta del protocolo, copia auténtica de la configuración y reloj local preciso. Son fallos distintos. Un dispositivo comprometido puede entregar claves privadas y texto sin cifrar; un estado local revertido puede hacer olvidar verificaciones anteriores; una hora incorrecta puede convertir una vista caducada en aparentemente válida.

El texto apunta a defensas concretas. La transparencia de binarios registraría públicamente cada versión antes de que los clientes la instalaran, dificultando que una actualización dirigida a una sola persona pase inadvertida. Código abierto y compilaciones reproducibles ayudarían a comprobar qué hace cada versión. Para el dispositivo y el reloj menciona otras medidas, entre ellas arranque verificado, almacenamiento de claves respaldado por hardware y tiempo autenticado desde servidores independientes.

El borrador no identifica un ataque real ni afirma que esos controles estén desplegados. Su aporte es señalar el punto exacto donde una garantía del registro depende de una decisión de distribución del operador. La ficha del Datatracker muestra un trabajo activo del grupo enviado a la IESG para publicación. Una prueba matemática en el servidor no dice qué programa recibió el teléfono.