Herramientas de desarrollo · UUID generador
Versión 1 Los UUID pueden filtrar su dirección MAC y la hora de creación
· Por qué es importante
uuid criptografía APIS del navegador
Un UUID basado en tiempo incorpora una marca de tiempo de 60 bits y un identificador de nodo de 48 bits que suele ser una dirección de tarjeta de red real. Esta publicación muestra lo que un extraño puede leer de uno y por qué la generación aleatoria evita el problema.
El identificador que da nombre a su computadora portátil: por qué una identificación en un documento exportado puede ser más que una identificación
Una versión 1 UUID se construye a partir de una marca de tiempo, una dirección MAC y un valor de secuencia de reloj. La marca de tiempo de 60 bits representa el número de intervalos de 100 nanosegundos desde el 15 de octubre del 1582, la fecha de la reforma del calendario gregoriano. El campo de nodo de 48 bits tradicionalmente contiene la dirección MAC IEEE 802 de la interfaz de red que generó UUID. Cuando exporta un documento, ejecuta una herramienta o guarda un archivo que incorpora una versión 1 UUID, cualquiera que luego decodifique ese UUID puede leer cuándo se creó y, si el campo del nodo es una dirección MAC real, qué máquina lo creó. Esta información se filtra silenciosamente desde lo que parece ser un identificador opaco.
Anatomía de una v1 UUID: los campos de marca de tiempo, la secuencia de reloj y el campo de nodo, y dónde se ubica cada uno en los caracteres 36
La filtración de información es sutil pero tiene consecuencias para la privacidad y la atribución. Si colabora con un coautor en un documento y la dirección MAC de su tarjeta de red está en los UUID v1 integrados, un observador aprende el hardware en uso en una institución o ubicación en particular. Si exporta un documento en un momento específico, la marca de tiempo en cada v1 UUID limita cuando ocurrió el trabajo. Un autor que intenta mantener el seudónimo puede ser anonimizado correlacionando la marca de tiempo UUID con fechas de publicación conocidas o eventos de creación de documentos. Los identificadores parecen inofensivos porque están formateados como cadenas opacas de 36 caracteres, pero no son opacos en absoluto para cualquiera que conozca el formato v1 y se interese en decodificarlos.
Qué aprende un observador: cuándo se creó el registro y, si el nodo es una dirección de hardware, qué máquina o proveedor lo creó
La anatomía de una v1 UUID aclara lo que se puede extraer porque la estructura es determinista y está documentada públicamente. RFC 9562 define el diseño: 32 bits para time_low, 16 bits para time_mid, 4 bits para la versión establecida en 1, 12 bits para time_high, 2 bits para variante, 14 bits para clock_seq y 48 bits para el nodo. Los campos de tiempo comprenden 60 bits en total, que cuando se combinan e interpretan como intervalos de 100 nanosegundos desde 1582 producen el instante de creación exacto dentro de 100 nanosegundos. El campo de nodo 48 bits generalmente contiene la dirección MAC como un entero de 48 bits. La decodificación es determinista: lee los bytes, enmascara y cambia los campos e interpreta los valores. No se trata de criptografía; la estructura UUID hace que la codificación sea completamente transparente y reversible.
Una historia de advertencia: cómo se han utilizado los identificadores incorporados en los documentos para rastrear la autoría, descrito sin especulaciones
RFC 9562 reconoce el historial de privacidad y recomienda no v1 para nuevas aplicaciones porque los costos superan los beneficios. La especificación incluye alternativas v4 aleatorias y v7 ordenadas en el tiempo con consideraciones de privacidad documentadas. La versión 1 se conserva por motivos de compatibilidad con sistemas implementados, pero el nuevo código no debe generar UUID v1 sin una revisión de seguridad cuidadosa y una justificación explícita de la exposición. La vulnerabilidad no fue un descuido; fue una elección de diseño deliberada en la década de 1980, cuando las fugas de privacidad no eran preocupaciones principales y el seguimiento era una característica aceptable para la identificación de sistemas distribuidos.
Ejemplo resuelto: decodificar una muestra v1 UUID a mano en su marca de tiempo y campos de nodo
La línea de tiempo es importante para comprender la exposición porque una v1 UUID en un documento creado en 1998 incluye una marca de tiempo que codifica el tiempo de la era 1998, lo cual es útil para los análisis forenses pero es el problema en sí. Si tiene documentos históricos con UUID v1 y luego los comparte, las marcas de tiempo persisten. No se puede eliminar retroactivamente el hecho histórico de que se generó un UUID en un momento determinado; solo puede dejar de generar nuevos UUID v1. Algunas aplicaciones intentaron mitigar la fuga de direcciones MAC reemplazando la MAC real con un seudónimo aleatorio, pero la marca de tiempo sigue siendo completamente legible y decodificable.
Qué cambian v4 y v7: los UUID aleatorios no contienen datos de máquina; v7 todavía revela el tiempo de creación, que puede ser aceptable o no
Un ejemplo resuelto muestra la decodificación en la práctica utilizando vectores de ejemplo RFC 9562. Tome una v1 UUID como f81d4fae-7dec-11d0-a765-00a0c91e6bf6 de la especificación. Los bytes en orden son f81d4fae 7dec 11d0 a765 00a0c91e6bf6. El campo de versión está en el tercer grupo: 11d0 en hexadecimal es 0001 0001 1101 0000 en binario. Los primeros 4 bits son 0001, que es la versión 1. La marca de tiempo se divide entre el primer, segundo y parte del tercer grupo: time_low es f81d4fae en decimal 4170404526, time_mid es 7dec en decimal 32236, time_high es 1d0 del tercer grupo después de eliminar la versión nibble en decimal 464. Combinarlos en un valor de 60 bits da un número que representa intervalos de 100 nanosegundos desde 1582.
Lo que esto no cubre: la opción de nodo aleatorio que ofrecen algunas implementaciones v1, que mitiga pero no elimina la fuga de marca de tiempo
El campo de nodo en los grupos cuarto y quinto es a765 00a0c91e6bf6, que codifica información de la máquina si el bit 0 indica autenticidad. Si el bit menos significativo del primer octeto del campo de nodo es cero, indica una dirección IEEE real; si se establece en uno, indica un valor pseudoaleatorio generado para privacidad. En este ejemplo, a765 en hexadecimal es 10100111 01100101 en binario; el bit menos significativo es 1, por lo que se trata de un pseudonodo aleatorio, no de una MAC real. Sin embargo, las implementaciones más antiguas a veces almacenaban direcciones MAC reales directamente y, si lo hacían, el campo del nodo 48 bits se decodifica en un identificador de tarjeta de red. IEEE mantiene un registro de prefijos MAC; Saber que una tarjeta de red comienza con un determinado prefijo limita el fabricante y, potencialmente, el modelo de computadora en uso.
Conclusión: conozca lo que revelan sus ID: el generador ToolAcre extrae todos los identificadores del CSPRNG, por lo que no hay dirección MAC ni marca de tiempo que se pueda filtrar
RFC 9562 versión 4 y posteriores eviten deliberadamente esta filtración utilizando solo datos aleatorios en lugar de información codificada. Una versión 4 UUID son 122 bits de datos criptográficamente aleatorios con 4 bits para el campo de versión y 2 bits para el campo de variante. La lectura de los bits no revela nada excepto que UUID es válido; no hay marca de tiempo que decodificar ni datos de máquina que extraer. La versión 7 incluye una marca de tiempo para ordenar los beneficios, pero esa marca de tiempo se deriva de la época familiar y estandarizada de Unix en lugar del oscuro valor basado en 1582, y la especificación documenta explícitamente que la información de tiempo está presente en el identificador. Las propiedades de privacidad difieren fundamentalmente entre versiones.