Инструменты разработчика · Генератор UUID
UUID версии 1 может раскрыть ваш MAC адрес и время создания
· Почему это важно
uuid криптография API-интерфейс браузера
Основанный на времени UUID включает 60-битную метку времени и 48-битный идентификатор узла, который часто является реальным адресом сетевой карты. В этом посте показано, что может прочитать посторонний человек и почему случайная генерация позволяет избежать этой проблемы.
Идентификатор, который называет ваш ноутбук — почему идентификатор в экспортированном документе может быть больше, чем идентификатор
Версия 1 UUID состоит из метки времени, адреса MAC и значения тактовой последовательности. 60-битная временная метка представляет собой количество 100-наносекундных интервалов с 15 октября 1582, даты реформы григорианского календаря. 48-битное поле узла традиционно содержит IEEE 802 MAC адрес сетевого интерфейса, сгенерировавшего UUID. Когда вы экспортируете документ, запускаете инструмент или сохраняете файл, в который встроена версия 1 UUID, любой, кто позже декодирует этот UUID, сможет прочитать, когда он был создан, и, если поле узла является реальным адресом MAC, то, на каком компьютере он был создан. Эта информация незаметно просачивается из непрозрачного идентификатора.
Анатомия v1 UUID — поля меток времени, последовательность часов и поле узла, а также расположение каждого из символов 36.
Утечка информации незаметна, но имеет последствия для конфиденциальности и атрибуции. Если вы сотрудничаете с соавтором документа и адрес MAC вашей сетевой карты находится во встроенных UUID версии 1, наблюдатель узнает, какое оборудование используется в конкретном учреждении или месте. Если вы экспортируете документ в определенное время, временная метка в каждой версии 1 UUID привязана к моменту выполнения работы. Автора, пытающегося сохранить псевдонимность, можно деанонимизировать, сопоставив временную метку UUID с известными датами публикации или событиями создания документа. Идентификаторы кажутся безобидными, поскольку они отформатированы как непрозрачные строки из 36 символов, но они совсем не непрозрачны для тех, кто знает формат v1 и хочет их декодировать.
Что узнает наблюдатель — когда была создана запись и, если узел является аппаратным адресом, какая машина или поставщик ее создали.
Анатомия v1 UUID поясняет, что можно извлечь, поскольку структура детерминирована и публично задокументирована. RFC 9562 определяет макет: 32 bits для time_low, 16 bits для time_mid, 4 bits для версии, установленной на 1, 12 bits для time_high, 2 bits для варианта, 14 bits для clock_seq и 48 bits для узла. Поля времени содержат общее количество 60 bits, которое при объединении и интерпретации как интервалы 100 наносекунд, начиная с 1582, дает точный момент создания с точностью до 100 наносекунд. Поле узла 48 обычно содержит адрес MAC как целое число 48. Декодирование является детерминированным: читайте байты, маскируйте и сдвигайте поля и интерпретируйте значения. Никакая криптография не используется; Структура UUID делает кодирование полностью прозрачным и обратимым.
Поучительная история: как идентификаторы, встроенные в документы, использовались для отслеживания авторства, описанная без домыслов.
RFC 9562 признает историю конфиденциальности и рекомендует не использовать версию 1 для новых приложений, поскольку затраты перевешивают преимущества. Спецификация включает в себя случайные альтернативы v4 и v7, упорядоченные по времени, с документированными соображениями конфиденциальности. Версия 1 сохраняется для обратной совместимости с развернутыми системами, но новый код не должен генерировать UUID версии 1 без тщательной проверки безопасности и явного обоснования использования. Уязвимость не была недосмотром; это был осознанный выбор в 1980-х годах, когда утечка конфиденциальной информации не была основной проблемой, а отслеживание было приемлемой функцией для идентификации распределенной системы.
Рабочий пример — декодирование образца v1 UUID вручную в его поля метки времени и узла.
Временная шкала важна для понимания воздействия, поскольку v1 UUID в документе, созданном в 1998, включает временную метку, кодирующую время эпохи 1998, что полезно для криминалистики, но само по себе является проблемой. Если у вас есть исторические документы с UUID версии 1, и вы позже поделитесь ими, метки времени сохранятся. Вы не можете задним числом удалить тот исторический факт, что UUID был создан в определенное время; вы можете только прекратить генерировать новые UUID v1. Некоторые приложения пытались уменьшить утечку адреса MAC, заменяя настоящий MAC случайным псевдонимом, но временная метка остается полностью читаемой и декодируемой.
Что изменилось в v4 и v7 — случайные UUID не несут машинных данных; v7 по-прежнему показывает время создания, что может быть приемлемым, а может и нет.
Проработанный пример показывает декодирование на практике с использованием векторов RFC 9562. Возьмите v1 UUID, например f81d4fae-7dec-11d0-a765-00a0c91e6bf6 из спецификации. Байты по порядку: f81d4fae 7dec 11d0 a765 00a0c91e6bf6. Поле версии находится в третьей группе: 11d0 в шестнадцатеричном формате — это 0001 0001 1101 0000 в двоичном формате. Первыми 4 bits являются 0001, это версия 1. Метка времени разделена на первую, вторую и часть третьей группы: time_low — f81d4fae в десятичном формате 4170404526, time_mid — 7dec в десятичном формате 32236, time_high — 1d0 из третьей группы после удаления полубайта версии в десятичном формате 464. Объединение их в 60-битное значение дает число, представляющее 100-наносекундные интервалы с момента 1582.
Что это не охватывает — опция рандомизированного узла, предлагаемая некоторыми реализациями v1, которая смягчает, но не устраняет утечку метки времени.
Поле узла в четвертой и пятой группах — a765 00a0c91e6bf6, которое кодирует машинную информацию, если бит 0 указывает на подлинность. Если младший бит первого октета поля узла равен нулю, это указывает на реальный адрес IEEE; если установлено значение «1», это указывает на псевдослучайное значение, созданное для обеспечения конфиденциальности. В этом примере a765 в шестнадцатеричном формате — это 10100111 01100101 в двоичном формате; младший бит — 1, так что это случайный псевдоузел, а не настоящий MAC. Однако более старые реализации иногда сохраняли реальные адреса MAC напрямую, и если они это делали, 48-битное поле узла декодируется в идентификатор сетевой карты. IEEE поддерживает реестр префиксов MAC; знание того, что сетевая карта начинается с определенного префикса, сужает производителя и, возможно, модель используемого компьютера.
Вывод: знайте, что раскрывают ваши идентификаторы — генератор ToolAcre извлекает каждый идентификатор из CSPRNG, поэтому нет адреса или временной метки MAC, которые могли бы утечь.
RFC 9562 версии 4 и более поздних версий намеренно избегают этой утечки, используя только случайные данные, а не закодированную информацию. Версия 4 UUID представляет собой 122 bits криптографически случайных данных с 4 bits для поля версии и 2 bits для поля варианта. Чтение битов ничего не показывает, кроме того, что UUID действителен; нет ни временной метки, которую нужно декодировать, ни машинных данных, которые нужно извлечь. Версия 7 включает временную метку для сортировки преимуществ, но эта временная метка получена из знакомой и стандартизированной эпохи Unix, а не из непонятного значения на основе 1582, и спецификация явно документирует, что информация о времени присутствует в идентификаторе. Свойства конфиденциальности в разных версиях существенно различаются.