Ferramentas para desenvolvedores · Gerador UUID
UUIDs da versão 1 podem vazar seu endereço MAC e hora de criação
· Por que é importante
uuid criptografia APIs do navegador
Um UUID baseado em tempo incorpora um carimbo de data/hora de 60 bits e um identificador de nó de 48 bits que geralmente é um endereço de placa de rede real. Esta postagem mostra o que um estranho pode ler e por que a geração aleatória evita o problema.
O identificador que dá nome ao seu laptop — por que um ID em um documento exportado pode ser mais do que um ID
Uma versão 1 UUID é construída a partir de um carimbo de data/hora, um endereço MAC e um valor de sequência de relógio. O carimbo de data/hora de 60 bits representa o número de intervalos de 100 nanossegundos desde 15 outubro 1582, a data da reforma do calendário gregoriano. O campo do nó 48 bits tradicionalmente contém o endereço IEEE 802 MAC da interface de rede que gerou o UUID. Ao exportar um documento, executar uma ferramenta ou salvar um arquivo que incorpore uma versão 1 UUID, qualquer pessoa que posteriormente decodificar esse UUID poderá ler quando ele foi criado e, se o campo do nó for um endereço MAC real, qual máquina o criou. Esta informação vaza silenciosamente do que parece ser um identificador opaco.
Anatomia de um UUID v1 — os campos de carimbo de data/hora, a sequência do relógio e o campo do nó, e onde cada um fica nos caracteres 36
O vazamento de informações é sutil, mas tem consequências para a privacidade e atribuição. Se você colaborar com um coautor em um documento e o endereço MAC da sua placa de rede estiver nos UUIDs v1 incorporados, um observador aprenderá o hardware em uso em uma determinada instituição ou local. Se você exportar um documento em um horário específico, o carimbo de data/hora em cada v1 UUID limita quando o trabalho ocorreu. Um autor que tenta manter o pseudonimato pode ser desanonimizado correlacionando o carimbo de data/hora UUID com datas de publicação conhecidas ou eventos de criação de documentos. Os identificadores parecem inócuos porque são formatados como strings opacas de 36 caracteres, mas não são opacos para quem conhece o formato v1 e se preocupa em decodificá-los.
O que um observador aprende — quando o registro foi criado e, se o nó for um endereço de hardware, qual máquina ou fornecedor o criou
A anatomia de uma v1 UUID esclarece o que pode ser extraído porque a estrutura é determinística e documentada publicamente. RFC 9562 define o layout: 32 bits para time_low, 16 bits para time_mid, 4 bits para versão definida como 1, 12 bits para time_high, 2 bits para variante, 14 bits para clock_seq e 48 bits para nó. Os campos de tempo compreendem o total de 60 bits, que quando combinados e interpretados como intervalos de 100 nanossegundos desde 1582 produzem o instante exato de criação dentro de 100 nanossegundos. O campo do nó 48 bits geralmente contém o endereço MAC como um número inteiro de 48 bits. A decodificação é determinística: leia os bytes, mascare e desloque os campos e interprete os valores. Nenhuma criptografia está envolvida; a estrutura UUID torna a codificação completamente transparente e reversível.
Uma história preventiva — como os identificadores incorporados em documentos foram usados para rastrear a autoria, descrita sem especulação
RFC 9562 reconhece o histórico de privacidade e não recomenda a versão 1 para novos aplicativos porque os custos superam os benefícios. A especificação inclui alternativas v4 aleatórias e v7 ordenadas por tempo com considerações de privacidade documentadas. A versão 1 é mantida para compatibilidade retroativa com sistemas implantados, mas o novo código não deve gerar UUIDs v1 sem uma revisão de segurança cuidadosa e uma justificativa explícita para a exposição. A vulnerabilidade não foi um descuido; foi uma escolha de design deliberada na década de 1980, quando os vazamentos de privacidade não eram as principais preocupações e o rastreamento era um recurso aceitável para identificação de sistemas distribuídos.
Exemplo resolvido - decodificando uma amostra v1 UUID manualmente em seu carimbo de data / hora e campos de nó
A linha do tempo é importante para entender a exposição porque uma v1 UUID em um documento criado em 1998 inclui uma codificação de carimbo de data/hora da era 1998, que é útil para análise forense, mas é o problema em si. Se você tiver documentos históricos com UUIDs v1 e compartilhá-los posteriormente, os carimbos de data/hora persistirão. Você não pode remover retroativamente o fato histórico de que um UUID foi gerado em um determinado momento; você só pode parar de gerar novos UUIDs v1. Alguns aplicativos tentaram mitigar o vazamento do endereço MAC substituindo o MAC real por um pseudônimo aleatório, mas o carimbo de data/hora permanece totalmente legível e decodificável.
O que as versões 4 e 7 mudam – UUIDs aleatórios não carregam dados de máquina; v7 ainda revela o horário de criação, que pode ou não ser aceitável
Um exemplo resolvido mostra a decodificação na prática usando vetores de exemplo RFC 9562. Pegue uma v1 UUID como f81d4fae-7dec-11d0-a765-00a0c91e6bf6 da especificação. Os bytes em ordem são f81d4fae 7dec 11d0 a765 00a0c91e6bf6. O campo de versão está no terceiro grupo: 11d0 em hexadecimal é 0001 0001 1101 0000 em binário. Os primeiros 4 bits são 0001, que é a versão 1. O carimbo de data / hora é dividido no primeiro, segundo e parte do terceiro grupo: time_low é f81d4fae em decimal 4170404526, time_mid é 7dec em decimal 32236, time_high é 1d0 do terceiro grupo após remover o nibble da versão em decimal 464. Combiná-los em um valor de 60 bits fornece um número que representa intervalos de 100 nanossegundos desde 1582.
O que isso não cobre — a opção de nó aleatório que algumas implementações v1 oferecem, que atenua, mas não remove o vazamento de carimbo de data/hora
O campo do nó no quarto e quinto grupos é a765 00a0c91e6bf6, que codifica as informações da máquina se o bit 0 indicar autenticidade. Se o bit menos significativo do primeiro octeto do campo do nó for zero, indica um endereço IEEE real; se definido como um, indica um valor pseudoaleatório gerado para privacidade. Neste exemplo, a765 em hexadecimal é 10100111 01100101 em binário; o bit menos significativo é 1, então este é um pseudonó aleatório, não um MAC real. No entanto, implementações mais antigas às vezes armazenavam endereços MAC reais diretamente e, se o fizessem, o campo do nó 48 bits era decodificado para um identificador de placa de rede. IEEE mantém um registro de prefixos MAC; saber que uma placa de rede começou com um determinado prefixo restringe o fabricante e, potencialmente, o modelo do computador em uso.
Conclusão: saiba o que seus IDs revelam — o gerador ToolAcre extrai todos os identificadores de CSPRNG, portanto, não há endereço ou carimbo de data/hora MAC para vazar
RFC 9562 versão 4 e posteriores evitam deliberadamente esse vazamento usando apenas dados aleatórios em vez de informações codificadas. Uma versão 4 UUID é 122 bits de dados criptograficamente aleatórios com 4 bits para o campo de versão e 2 bits para o campo de variante. A leitura dos bits não revela nada, exceto que UUID é válido; não há registro de data e hora para decodificar, nem dados de máquina para extrair. A versão 7 inclui um carimbo de data e hora para classificar os benefícios, mas esse carimbo de data e hora é derivado da época Unix, familiar e padronizado, em vez do valor obscuro baseado em 1582, e a especificação documenta explicitamente que as informações de tempo estão presentes no identificador. As propriedades de privacidade diferem fundamentalmente entre as versões.