dxdt.ru: занимательный интернет-журнал

Заметка на dxdt.ru из 2009 года, рассказывающая о том, как идентифицировать пользователя приложения по отметкам геолокации:

Прежде, отметим один момент: формальной анонимности пользователя вовсе не противоречит создание на сервисе уникального аккаунта, привязанного к данной копии программы. Это необходимо и для обновлений, и для придания устойчивости системе в целом (помогает бороться с “поддельными запросами” злых хакеров и т.д.) Только по аккаунту личность пользователя установить нельзя.

Теперь о том, как же вычислить пользователя. Вот как: фиксируются его места пребывания в рабочее время, и в не рабочее время. Приехал человек на работу, находится долго “на одном месте” – несложно вычислить и место, и, собственно, рабочее время, так как людям свойственно действовать по некоторому графику. Вычисляется всё автоматически, никакой “сложной эвристики”.

За прошедшие годы актуальность только выросла: вспомните про суперпопулярные нынче приложения для “анонимного отслеживания контактов”.

(Заметка первоначально опубликована в Facebook, 19/05/2020.) Я вот так устроил, что один сервис, проверяющий TLS, использует специально сконструированное сообщение ClientHello TLS 1.3 (см. скриншот) с посланиями внутри. Небольшая хитрость состоит в том, что там не только поля SessionID и ClientRandom с сообщениями, но и ключ для Диффи-Хеллмана (ECDH) на кривой P-256 – с посланием. Ключ – это два числа, но они должны задавать точку кривой, и хорошие реализации TLS проверяют, что ключ принадлежит кривой. Конечно, вычисление второй координаты Y по известной X-координате – никакой проблемы не составляет, но пришлось урезать пару символов, так как число приводится по порядку базового поля. У тех, кто знаком с ECDH, сразу возникнет вопрос – решил ли я попутно задачу дискретного логарифмирования для P-256? Но нет (а если бы решил, то сообщил бы об этом более занятным способом). Дело в том, что реально в этом сканере общий секрет не нужен, поэтому ответный ключ сервера просто игнорируется. (Конечно, вряд ли кто-то ещё это всё видит в трафике. Но при отладке – помогает.)

А вот десять лет назад, в мае 2012 года, на dxdt.ru, например, была опубликована заметка про автономный персональный навигационный компьютер:

Итак, речь о достаточно компактном электронном устройстве, которое выполняет функции типичного современного GPS-навигатора (карты, экран, показывает местоположение в реальном времени), но при этом не зависит от рукотворных внешних источников навигационной информации. Понятно, что электронная начинка, операционные системы подходят от современных навигаторов. С исходными картами тоже более или менее понятно: загрузили файлы в память, используем. Конечно, карты будут устаревать. Это особенно вероятно в ситуации, приведшей к разрушению важных для Цивилизации элементов инфраструктуры – GPS, сотовой связи. Они явно отключились неспроста. Но леса, реки, холмы, поля и озёра – заведомо остаются на своих местах. Как и многие здания, кстати. Да и прочие изменения происходят не столь быстро, чтобы картографические файлы оказались совсем бесполезны.

Запись чисел при помощи цифр различных систем счисления нередко приводит к недопониманию у тех, кто не очень хорошо представляет себе разницу между числами и их записью. Например, могут предположить, что 11 и 0x11 (в шестнадцатеричной записи, далее такая запись обозначается привычным префиксом) это одно и то же число, ну, как 7 и 0x7. Нетрудно наткнуться и на смешение свойств числа и его записи: то есть, на неверное представление о том, что какие-то свойства чисел соответствуют именно записи (запутывающее сочетание 0x100 == 2^8). Впрочем, всё это не мешает занимательным свойствам позиционных систем счисления интересным образом преобразовываться при переходе от одной системы к другой, сохраняя именно запись (то есть, цифры).

Так, если 1001001 умножить на 321, то получим 321321321. Почему? Очевидно: мы умножаем (10^6 + 10^3 + 10^0) на (10^2*3 + 10^1*2 + 10^0*1), то есть (10^6 + 10^3 + 10^0)*321. Известный, пусть и не очень широко, факт: всякое число, содержащие ровно три одинаковых тройки цифр в своей записи, делится на 333667. Примеры:
321321321/333667 == 963 == 3^2 * 107
111111111/333667 == 333 == 3 * 111
701701701/333667 == 2103 == 3 * 701

(Конструкция, конечно, переносится и на кратные записи, то есть, когда количество триплетов кратно трём.)

Выглядит занимательно. Причина в том, что на 333667 делится 1001001 == 3*333667. А 333667 – простое число. В записи 333667 нетрудно увидеть поразрядные “переносы единицы” при умножении на три. Можно ли найти число с такими же свойствами в шестнадцатеричной записи? Можно. Если в десятичной записи 3*3 == 9 == 10 – 1, где 10 – основание системы, то в шестнадцатеричной аналогом будет 3*5 == 15 == 0x10 – 1. Обратите внимание, что здесь 0x10 шестнадцатеричная запись числа 16, основания системы. Число другое, но нам здесь важны как раз некие свойства записи (а именно – позиция единицы). Искомое число – 0x555aab. Заметьте, что шестнадцатеричное 0xa равно 10 в десятичной системе, то есть, 5*2 (так же как и 3*2 == 6). Проверяем: 0x555aab * 0x3 == 0x1001001 (но это 16781313 в десятичной записи). Поэтому 0x321321321 делится на 0x555aab, а результат равен 0x963 (см. примеры в десятичной системе выше). Однако найденное нами “опорное” число хоть и полностью подходит по “свойствам” записи, но является составным: 0x13*0x25*0x49*0x6d == 0x555aab.

А вот в восмеричной системе ситуация иная. Число 0o1001001 (префикс 0o – обозначает восмеричную запись) – простое, а именно – 262657 == 8^6 + 8^3 + 8^0. Поэтому не получится найти делитель, который подходил бы для построения конструкции, аналогичной десятичной и шестнадцатеричной системам. Интересно, что число 46656216001 == 60^6 + 60^3 + 60^0 тоже простое. Это означает, что и в древней шестидесятеричной системе конструкция не сработает. Что ж, зато в десятичной системе 296296296296296296296296296/333667 == 888000000888000000888. Проверьте на калькуляторе.

Некоторые странные заблуждения из области “научпопа” очень долговечны. Например, если заглянуть в статью про Галилея в русскоязычной “Википедии”, то нетрудно обнаружить типовые суждения в стиле “Галилей опроверг (мета)физику Аристотеля”. “Википедия”, конечно, здесь выступает лишь фольклорным зеркалом истории физики, но тем рельефнее выглядит цитата: “В частности, Аристотель утверждал: скорость падения пропорциональна весу тела; движение происходит, пока действует «побудительная причина» (сила), и в отсутствие силы прекращается”.

Да, Аристотель подобное утверждал, но с очень важной оговоркой, которая полностью меняет ситуацию. Аристотель изучал падение тел в среде и рассуждал о максимальной скорости падающего тела. Утверждения Аристотеля, процитированные выше, хорошо соответствуют эксперименту. Действительно, в воздухе свинцовый шарик и клочок ваты, сравнимого размера, будут падать с разной максимальной скоростью, потому что у них различный вес. Конечно, другое дело – вакуум. Однако Аристотель изучал падение не в вакууме. Понятно, что то же самое относится и к “побудительной силе”, если учитывать реальные условия. Поэтому хорошо бы и формулировать иначе: Аристотель утверждал, что при падении в среде, – например, в воздухе, – максимальная скорость, которой может достичь тело, пропорциональна его весу. Но при такой формулировке исчезает вся сенсационность. Получается, что Галилей не “опровергал физику”, а всего лишь обобщил ограничивающие свойства, обусловленные наличием среды, и предложил другую модель, в чём-то более универсальную. Кроме того, всё это знали другие естествоиспытатели, раньше Галилея. Надо заметить, такая интерпретация сильно богаче с точки зрения философии науки, но менее литературна. Поэтому в “Википедии” читаем: “Галилей сформулировал правильные законы падения: скорость нарастает пропорционально времени”. Занятно выглядит слово “правильные”. Как можно понять, что какие-то законы физики – правильные? А если вы сравниваете разные модели при различных “граничных условиях”? Физика, вообще говоря, не претендует на “правильность законов”.

Ссылка по теме: Aristotle’s Physics: a Physicist’s Look, Carlo Rovelli.

Добавил в “Избранные записки” пару новых: “TLS для DevOps” и “Хитрости записи корней уравнений“.

Надо заметить, что записок десятилетней давности, за апрель 2012 года, на dxdt.ru не очень-то много. Но вот, всё же, цитата из небольшой заметки по теории методов РЭБ: “Это означает, что состоянием комплекса можно манипулировать, создавая активные помехи (так выстраивается один из путей активации аппаратных закладок, если таковые имеются в вычислительных системах)”. За прошедшее время тема аппаратных закладок развилась и перешла в область гражданских вычислительных систем. Впрочем, каких-то технически содержательных “обнаружений” “в публичной печати” так и не случилось, но случились известные “разоблачения Сноудена”.

Ракета (из прошлых записок):

Если из браузера утекают сеансовые ключи, то расшифровывать TLS-трафик можно в пассивном режиме, и не потребуются никакие “перехватывающие удостоверяющие центры”. А намеренную утечку может организовать сам браузер. Или другой клиент TLS. А также и сервер. Довольно интересно в этом контексте выглядит распространённая сейчас в мире персональных компьютеров ситуация, когда TLS-трафик перехватывает и проксирует локальный антивирус.

Традиционно, подобные механизмы “контролируемых утечек” в криптологии основываются на “порче” алгоритма вычисления псевдослучайных чисел (см. хрестоматийный пример про DUAL_EC DRBG). Так, в современных реализациях TLS сеансовый секрет вычисляется по алгоритму Диффи-Хеллмана (DH). Если в результате утечки третьей стороне станет известен клиентский секрет DH (то есть, секрет браузера), то эта сторона сможет вычислить симметричные ключи защиты трафика и всё расшифровать в пассивном режиме. При использовании “испорченного” программного генератора псевдослучайных чисел браузеру достаточно передать третьей стороне состояние генератора, в котором он находился перед тем, как были запрошены случайные числа для секрета DH. Генератор, естественно, детерминированный, поэтому, зная его полное состояние, нетрудно вычислить вывод (то есть, секрет DH). Грамотный подход подразумевает, что авторизованная третья сторона знает некоторый дополнительный ключ, который даёт гарантию, что раскрыть данные утечки сможет только эта сторона, а не всякий, кто разгадал алгоритм и записал трафик (именно так было сделано в DUAL_EC DRBG).

Утечку можно организовать самыми разными способами. Например, начальные сообщения сеанса TLS содержат случайные значения, которые, конечно, могут быть “не совсем случайными”. Более ловкие варианты основаны на манипуляции длиной сообщений (или пакетов данных), на передаче дополнительных параметров и так далее. Главное – каким-то способом поставить измеримую характеристику трафика в зависимость от состояния генератора псевдослучайных чисел клиента. Самое занимательное, что наличие такой зависимости может быть неплохо обосновано “желанием замаскировать метаинформацию о соединении”.

А использование подменного УЦ – это довольно грубый метод. Который, во-первых, требует активного перехвата соединения; во-вторых – оставляет надёжные, хорошо заметные следы.