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

На фоне озвучиваемых в СМИ планов по созданию новых государственных сервисов в национальном кириллическом домене интересно взглянуть на адресацию в Интернете с точки зрения “главных рубильников”.

Понятно, что всякий интернет-сервис намертво привязан к двум фундаментальным штукам: DNS (то есть, имена доменов) и IP (то есть, сами адреса, по которым доставляются пакеты данных). В этом кроется принципиальное отличие интернет-среды от, скажем, радиоэфира.

Радиоэфир общий по своей физической сути. Есть международные соглашения, регулирующие использование спектра частот. Но, по большому счёту, если вдруг очень сильно потребуется организовать вещание на той или иной частоте, то ни у одной международной (или просто коммерческой) организации не найдётся средств, чтобы технически вещание полностью заблокировать. Да, можно ставить помеху, блокируя приём передач в некотором кусочке пространства. Можно, в общем, вести РЭБ. Но просто взять, нажать кнопку, и отключить доступ к частоте для всех слушателей и для вещателя – такого, очевидно, нельзя сделать.

Совсем другое дело – системы интернет-адресации. Здесь есть главные рубильники, и главные кнопки, которые позволяют очень быстро отключить частоту. Самый простой пример – удаление домена из файла зоны. Удалить можно не только домен второго уровня, но и домен первого уровня. В результате все сайты из него станут недоступны. Так как опрос DNS всегда начинается с корневых серверов, то внесение изменений в корневую зону позволяет не только отключить любой домен первого уровня, но и, например, перенаправить трафик внутри этого домена на другие адреса. Конечно, требуется административный доступ к корневой зоне DNS.

Посмотрим на сценарий с DNS чуть более детально. Предположим, что кому-то требуется перехватить управление некоторым национальным доменом. Адресация в национальном домене глобально определяется серверами имён, которые указаны для него в корневой зоне. Первый путь для перехвата: изменяется запись в корне, новая версия указывает на другие сервера имён. Часто можно услышать, что корневую зону поддерживает большое число корневых серверов (их – 13), узлы которых распределены по всему миру и находятся под управлением разных компаний. Это так. Но файл корневой зоны все эти серверы получают из одного источника, со скрытого сервера, управляемого компанией VeriSign. Соответственно, если изменить адреса в исходном файле, то при очередном обновлении изменения распространятся на все экземпляры корневой зоны.

После изменения адресов серверов имён в корневой зоне начнётся постепенное вытеснение старой информации об адресации в зоне (а она касается всех доменов уровнем ниже), из глобальной DNS. Постепенное – потому что записи на разных серверах кэшируются.

Понятно, что на новых серверах домена верхнего уровня может быть прописана совсем другая адресация. Но можно и сохранить имевшуюся на момент перехвата управления. Для этого потребуется заблаговременно получить файл зоны с действующих серверов имён. Этот файл содержит все записи о доменах уровнем ниже. Разместив на новых серверах имён копию старого файла зоны, можно замаскировать перехват: для пользователей ничего не изменится. (Конечно, файл зоны может быть “засекречен”, но, на уровне положения администраторов корня DNS, такой расклад выглядит непрактичным: ну реально ж попросить свежую копию заранее.)

Забрав управление доменом описанном незаметном режиме, новый администратор может переадресовать только какие-то ключевые сайты, оставив основную часть адресных настроек без изменений. Этот способ особенно хорош в том случае, если новый администратор не желает, чтобы под удар попали лояльные к нему интернет-сервисы: ведь понятно, что если “снести” домен полностью, то недоступными окажутся все ресурсы сразу; копирование установленной адресации – сильно смягчает ситуацию для рядовых пользователей. (Да, старые администраторы не смогут менять настройки доменов и т.п., и т.д. но это не так страшно.)

Заметьте, что изменение DNS коснётся и электронной почты в домене. Она начнёт ходить “не туда”.

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

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

(А при этом IP-адреса корневых серверов зашиты в системном программном обеспечении. Изменить их можно, но только в ручном режиме, при условии, тысячи системных администраторов будут действовать согласованно.)

Да, конечно, всё это теоретические сценарии. Но интересные. Так что, думаю, в следующих записках разбор темы можно продолжить. Тем более, что актуальность Интернета у нас растёт семимильными шагами.

Обсуждали тут аудит программного кода. Речь вот о чём: программное обеспечение, которое предназначено для решения каких-либо критичных задач, подвергают аудиту. Цели аудита: обнаружение возможных “закладок” и нехороших особенностей.

Для аудита можно использовать исходные коды. И их используют, потому что так удобнее. Есть разные автоматизированные инструменты и вообще – обкатанные подходы. Пример, который на слуху, аудит разработок Microsoft, для допуска к специальным компьютерам. Эта корпорация предоставляет исходники своих продуктов, на особых условиях.

Так вот, при обсуждении методов проверки “исходников” и получающихся результатов, нельзя забывать, что так же необходима проверка компиляторов и инструментов сборки исполняемых кодов. Если вы проверили “исходники” операционной системы (а там, кстати, миллионы строк) и ничего не нашли подозрительного, но при этом вообще не проверили компилятор, который эти исходники обрабатывает, то нельзя делать выводов об отсутствии закладок и дефектов – их может вносить компилятор.

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

Да и собирать продукт вообще-то нужно самостоятельно (как с опенсорсными решениями и происходит). Очевидно, что в противном случае можно получить “немного не тот” исполняемый код. (Другой способ, менее эффективный: хитрый криптографический контроль сборки, проводимой на стороне разработчика ПО.)

(Часто озвучиваемая идея с подробной сверкой бинарного кода собственной сборки (из проверяемых исходников), и “оригинального” дистрибутива – особого смысла не имеет. Посудите сами: если вы и так можете получить идентичный “оригиналу” бинарный код, настаивать на использовании “оригинала” производителю смысла нет. Если же производитель что-то там, якобы, подписывает своими секретными ключами, и этим мотивирует изменение исполняемого кода, то особого доверия ко всей процедуре аудита уже быть не может.)

Опять обсуждается тема с перехватом управления интернет-ресурсом через захват почтового ящика. В этот раз в связи с доменами. Интересно, что сама эта технология – она очень и очень старая, наверное, возраст сравним с возрастом e-mail. Время идёт, но мало что меняется: благодаря наличию напоминалок паролей, уровень безопасности кучи “персональных” ресурсов и сейчас часто сводится к уровню безопасности электронной почты, адрес которой указан в качестве контактного. Как действуют злоумышленники понятно: получил доступ к ящику, запросил новый пароль.

Если нет “двухфакторной” авторизации при смене пароля через напоминалку, то всё совсем просто. И обычно никакой двухфакторной авторизации как раз нет. Например, CMS-ки в ответ на запрос “забыл пароль” традиционно высылают одноразовый ключ, позволяющий залогиниться в админку (так делает Drupal и другие).

Занимательности добавляет тот факт, что “брошенные” адреса периодически становятся доступными для новой “регистрации” совсем другими пользователями. И это вовсе не исключительная проблема бесплатных почтовиков (пишут, что проблемные домены имели в контактах адреса @mail.ru, @bk.ru и т.п.). Да, с освободившимися аккаунтами бесплатной почты – всё понятно. Эти адреса вне конкуренции: освобождаются чаще, захватить проще. Однако есть же и другие способы.

Во-первых, освободиться может домен, на котором имелись контактные адреса. Зарегистрировав такой домен вновь, можно настроить MX-записи и – вся почта домена ваша. Во-вторых, перехватив домены через регистрацию почтового адреса на бесплатной почте, можно проделать с MX-ами то же самое, опять получив всю почту доменов. Понятно, что и взлом NS-ов также позволит переправить почту.

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

Некоторое время назад я завёл специальную страницу, иллюстрирующую возможности по имитации многоязычных доменов, открывающиеся перед фишерами, детали описаны в отдельной заметке. Если кратко: то фокус состоит в смешении нескольких таблиц unicode в одном адресе. Так как многоязычные доменные имена в DNS всё равно кодируются ASCII-символами (латиницей, проще говоря), а преобразование происходит на стороне приложений (не в DNS), то можно любую котовасию символов записать в многоязычный домен.

Так, адрес из примера графически имитирует домен второго уровня проверка.рф, используя для имитации символ деления из специальной таблицы unicode. Получается строка вот такого вида: http://проверка.рф⁄click.dxdt.ru/, где третья слева косая черта – это вовсе не “слеш”, как можно подумать, а сам домен находится в зоне .dxdt.ru. (которой управляю я), а не в .рф. Когда та заметка публиковалась, домен РФ ещё не работал (кириллическая ссылка на dxdt.ru – работала, конечно; чем впечатляла специалистов: “а как это так?” – спрашивали они). Сейчас зона .рф доступна. И поисковики индексируют сайты в ней.

Сейчас в google.ru по запросу “проверка.рф” первой выдаётся как раз ссылка на тестовую страничку http://проверка.рф⁄click.dxdt.ru/. При этом в тизере адрес записан именно в кириллическом виде, а не в нотации Punycode, с префиксом xn--, как должно бы было быть при смешении таблиц unicode в адресе. Что и требовалось доказать. Вот скриншот:

(Думаю, и после введения кириллических доменов останутся пользователи, предпочитающие набирать адрес сайта в поисковике и переходить по верхней ссылке. Но вообще пример говорит о другом: чем больше слоёв в преобразовании символьных записей адресов, тем больше возможностей для обмана бедных пользователей.)

Как это исправить? Понятно, что Google должен смешанные адреса в тизерах показывать в Punycode – то есть, вот так: http://xn--80adjurfhd.xn--click-uye2a8548c.dxdt.ru/

В конце мая Google, наконец-то, реализовал доступность поиска по HTTPS – https://www.google.com/. Правда, пока не все поисковые направления работают по защищённому протоколу, например, не поддерживает HTTPS поиск по изображениям. Да и вообще всё в статусе беты. Тем не менее, это важный шаг.

Так, у Google нашлось достаточно вычислительных мощностей, чтобы перевести на HTTPS один из самых своих массовых сервисов: нужно учитывать, что вычислительные затраты на работу по шифрованному каналу заметно больше, если сравнивать с простым HTTP. При работе с многими миллионами запросов – проблема с дополнительной нагрузкой встаёт в полный рост.

Но самое интересное-то в другом. Сейчас все пользователи постепенно переезжают в новый Интернет. В старом Интернете веб-трафик был сплошь открытым, из, так сказать принципиальных соображений. Всякий “любопытный”, имеющий доступ к каналам связи, мог этот трафик записывать, анализировать, фильтровать, подделывать и дополнять разными “инъекциями”. В новом Интернете каналы “точка-точка” – хорошо закрыты криптографическими средствами. И всякий узел удостоверяется электронной подписью.

Если строить аналогию, то можно представить, что участники сети перестали обмениваться между собой почтовыми открытками (которую может почитать каждый почтальон), а вместо этого перешли на хорошо заклеенные печатями непрозрачные конверты.

В ближайшие годы на HTTPS перейдёт ещё больше сайтов. Вряд ли, конечно, защищённая версия быстро полностью вытеснит открытый протокол – ведь используют же до сих пор FTP. Но доля трафика HTTPS сильно вырастет. Собственно, уже и только трафик Google – заметная прибавка.

При этом криптография активно внедряется и на уровне DNS – это DNSSEC, – и на уровне IP (здесь планируется сертификация маршрутов и автономных систем, с подписыванием ЭЦП анонсов BGP – об этом, наверное, нужно отдельную записку написать). Новый Интернет должен сформироваться уже лет через пять. Помимо перехода на HTTPS, важным моментом будет проталкивание поддержки DNSSEC на клиентские машины.

Вот в автомобильных сигнализациях сейчас сплошь используется обратная связь – блок в автомобиле передаёт некие сведения об изменении состояния на брелок (например). При этом, как часто утверждают, автосигнализации не устойчивы к перехвату радиосканером сигналов управления. Такой перехват, – понятно, с последующим воспроизведением, – делается угонщиками для снятия автомобиля с охраны. Ну, так пишут.

Задача разработчика охранной системы формулируется довольно просто: есть брелок, есть управляющий модуль на автомобиле, нужно обеспечить надёжный защищённый обмен командами через открытый эфир. (Всякие особенности, типа кражи брелока, расположения владельца относительно автомобиля в момент снятия с охраны и т.п., не учитываем.) Подобные задачи успешно решались давно. Из сложных реализаций с историей, можно, например, вспомнить системы гос.опознавания на самолётах.

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

Более сложное решение использует “одноразовые пароли”. Дистанционный брелок и автомобильный блок используют некий общий (уникальный относительно комплекта оборудования) секрет для генерации последовательностей ключей. Каждый ключ используется один раз. Повторная передача использованного ключа не работает. Требуется, чтобы и брелок и управляющий блок имели память и могли генерировать последовательности ключей. Это не очень сложно реализовать. Справится простой микроконтроллер.

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

Обкатаны и процедуры атаки. Стандартный подход напрашивается сразу же: нужно заставить брелок выдать несколько ключей в эфир, но так, чтобы до автомобильной части системы эти ключи не добрались. Реализация: в эфире ставится помеха, но таким образом, чтобы сканер ключ, выданный брелоком, принял. Неспециалисту часто кажется, что это нереальный расклад. А он – реальный. Помеху в эфире конструирует атакующий. Его задача – записать из эфира суммарный сигнал, содержащий и помеху, и ключ. Помеху потом можно вычесть, так как она известна. А вот блок приёмника на автомобиле может не справиться с отстройкой от помехи. Конечно, есть помехоустойчивое кодирование и другие способы защиты, но их реализация усложняет и саму аппаратуру автосигнализации, и процесс её разработки. Итак, вычисленный и записанный ключ (несколько ключей) – позже используются для “взлома” системы (если, конечно, не успеют выпасть из синхронного интервала).

Почему недостаточно хорошо работает этот “продвинутый” метод? Потому что отсутствует добротная аутентификация со схемой запрос-ответ. Не используется “обратная связь”, хотя она есть, как упомянуто в самом начале заметки.

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

Что получилась? Получилась схема, похожая на механизм из сетей GSM. Алгоритм, существенно более стойкий, чем вариант с простыми одноразовыми паролями. Правда, реализация тоже существенно сложнее. Например, в управляющем блоке не только должна быть память, а он также должен отслеживать “возраст” переданных в эфир запросов, отменять устаревшие, иначе схему легко “подвесить”, организовав что-то вроде DoS-атаки, путём имитации запросов брелока.

Злоумышленник может организовать гипотетическую атаку типа “человек посередине”, пытаясь имитировать работу автомобильного блока в ответ на старт сеанса связи. Но так как, в отличие от GSM, здесь авторизация начинается только по нажатию кнопки владельцем автомобиля, успех – скорее призрачен. Хотя, есть варианты. Да и никто не гарантирует, что в конкретной реализации алгоритма не обнаружат дыр.

Используя цифровые подписи и криптографию с открытым ключом, можно вообще организовать закрытый двусторонний канал связи между брелоком и автомобилем.

Итог: микроконтроллеры сейчас научились выпускать довольно мощные и очень компактные, с минимальным энергопотреблением. Микроконтроллеры при этом дешёвые. Алгоритмы защиты – известен. Вопрос такой: а защищены ли на практике все современные автосигнализации от перехвата команд?

Как сообщают, сегодня последний из корневых серверов DNS (J) перевели на DNSSEC (прогресс – здесь). То есть, с пятого мая все корневые серверы отдают подписанную зону. На этом, правда, процесс развёртывания DNSSEC не закончен. Сейчас зону специально “подписывают” с помощью “кривого” ключа, так, чтобы нельзя было проверить данные. Часто спрашивают – для чего это сделано? А для того, чтобы можно было с минимальными проблемами откатить всё обратно, если вдруг DNSSEC приведёт к краху DNS.

Объяснение разработчиков процедуры – такое: использование кривого ключа гарантирует, что особенно продвинутые участники глобальной Сети не перейдут на полную поддержку DNSSEC раньше времени. Действительно, с “кривым” ключом использовать DNSSEC на практике смысла нет, поэтому клиенты не станут массово и полностью внедрять поддержку новой технологии, так как они не смогут в таком случае работать с DNS. А вот если бы корневую зону подписывали сразу проверяемым образом, то откат оказался бы очень проблемным делом: те, кто перешли на DNSSEC уже не смогли бы работать с Сетью, если бы поддержку DNSSEC отключили.

Кстати, про новый национальный домен РФ уже столько построено “твёрдых” планов с графиками и столько раз сказано, что домен “уже выделен и начнёт работу” (включая сообщения, сделанные на самом высоком государственном уровне) – теперь если ICANN заупрямится, Координационному центру, видимо, придётся делегировать домен на собственных серверах, чтобы озвученные адреса заработали.

Современная DNS так устроена, что можно договориться с группой провайдеров и создать несанкционированное дополнение к корневой зоне (ну или просто поднять свой, независимый от управления ICANN, корень DNS). В такой “дополненной реальности” может работать любой новый домен верхнего уровня, неделегированный ICANN. Правда, доступен он будет только клиентам участников, так сказать, технического доменного картеля – то есть, только для тех пользователей, чьи интернет-провайдеры используют отличные от общемировых настройки DNS. Иными словами, за пределами сегмента Сети, в котором действуют свои собственные правила адресации, дополнение к DNS работать не будет.

(Про то, что теоретически такой вариант возможен для РФ – совершенно неожиданно упомянули представители Координационного центра на доменной секции в рамках РИФа. А вариант этот, мягко говоря, самый плохой из возможных.)

Например, не так давно “Гарант-Парк-Телеком” проделал фокус с независимым “открытием” домена РФ, создав на своих серверах домен “гарант-парк-телеком.рф” и предложив желающим изменить настройки серверов DNS так, чтобы этот домен заработал. Действия ввели в заблуждение многих несведущих в технических аспектах журналистов, поспешивших язвительно написать, что “на практике сайт гарант-парк-телеком.рф не открывается ни в одном браузере”, хотя он и не должен был открываться, так как Гарант-Парк-Телеком нарушил принципы построения глобального Интернета.

Преодоление этих самых принципов происходит приблизительно по следующей схеме рассуждений: а что нам эти RFC и IETF? мы сами с усами! Действительно, международной законодательной основы для функционирования Интернета – нет, а есть лишь некие соглашения и рекомендации (RFC), которым большинство участников обмена данными следуют. На определённом этапе развития ожидаемо появляются группы, которые считают, что “нам эти RFC – не указ!” и “мы сами знаем, как лучше, у нас есть свои инженеры и сети!”. И вот на следующем шаге строят собственные альтернативные корни DNS (они, кстати, есть уже развернутые, если кому интересно) и вообще сегменты как бы глобального Интернета, помещающие пользователя в “иную сетевую реальность”. (Примеры тут известны самого разного уровня, начиная от домовых сетей, в которых “понравившиеся домены” настраивали так, что они показывали совсем не на те ресурсы, на которые должны бы по задумке “глобально признанного администратора”. Обмануть ведь пользователя не сложно, можно так сделать, что он, набирая yandex.ru, будет попадать на локальный ресурс администратора сети).

Между прочим, практически то же самое можно проделать и с IP-адресами, если кто из подготовленных пользователей сомневается: просто, перенастройка таблиц маршрутизации и работы с BGP – несколько более сложное дело. Но проблема решаемая: работает же ведь технология anycast для IP-адресов распределённых сервисов.

Есть и известный способ оправдания действий по созданию альтернативных интернетов. Например, локально запустив домен РФ альтернативным способом, без делегирования в глобальном корне DNS, можно говорить так: “это только для тестирования; до тех пор, пока в корневой зоне этого домена нет, а как только он появится – сразу уберём свой альтернативный механизм”. Именно так, запуская альтернативы, всегда давили на ICANN, пытаясь принудить корпорацию к принятию нужных решений. Впрочем, хитрая ICANN давно научилась бороться с подобными попытками и обращает их эффект себе во благо.

Что интересно: ICANN появилась как раз для того, чтобы эффективно победить возникавшие десять лет назад альтернативные сегменты адресного пространства Интернета. Сейчас именно ICANN при прямом и активном участии Минторга США вводит новые эффективные инструменты противодействия провайдерам, которые “себе на уме” – это DNSSEC и новые политики сертифицирования распределения блоков IP-адресов. И в DNSSEC, и в распределении IP уже в самые ближайшие годы появятся криптографические механизмы, которые перекроют все простые ходы по подделке ответов DNS и перехвату адресов. При этом, в случае с DNSSEC, механизмы проверки будут проталкивать прямо на клиентскую машину, силами производителей операционных систем (выпустит, скажем, MS очередной апдейт – и вот, готово).

Вот.

P.S. Спасибо всем, кто таки пришёл на нашу секцию на РИФе. Данная заметка как раз написана по результатам обсуждения и ответов на вопросы в ходе секции.

Обсуждают вот взломы аккаунтов на Gmail. Суть такая: вдруг аккаунты некоторых пользователей гугловой почты оказались захвачены кем-то посторонним, и этот кто-то разослал по контактам из адресной книги сомнительные сообщения. При этом пострадавшие пользователи – хорошо подготовлены: используют стойкие пароли, ОС из класса Linux/Unix, по ссылкам не ходят, незнакомые файлы не запускают и так далее. То есть, выходит, что пароли у них увести сложно. Как же были вскрыты аккаунты?

Так вот среди вариантов “вскрытия” почему-то не упоминают сценарий, использующий атаку на уровне маршрутизации. А зря. Какой-нибудь “хакерский” интернет-провайдер, используя известные особенности BGP (протокол, определяющий межсетевую маршрутизацию в Интернете), может увести трафик с дата-центров “Гугла” (точнее – с определённых автономных систем) к себе. Дальше ему остаётся лишь прикинуться Гуглом и преспокойно перехватить сессии авторизации, тем более, что в таком случае можно заставить пользовательские браузеры приходить по http (вместо https, который, чисто в теории, мог бы затруднить подделку). Перехватываться будет часть глобального трафика Интернета, адресованная Гуглу, а вовсе не трафик клиентов провайдера, как можно подумать.

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

В общем, ждём новинок в обеспечении безопасности маршрутизации.

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

(Наверное, нужно напомнить, что в исходной заметке речь о том, какое будущее ждёт механические замки – ведь скоро появятся дешёвые, доступные сенсоры, способные в автоматическом режиме “просканировать” замок неразрушающими методами и реконструировать подходящий ключ, основываясь на компьютерном анализе внутренней структуры конкретного механизма.)

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

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

Возникает вопрос, как передавать на запирающий конструкцию элемент управляющие воздействия, если замок чисто механический? Ответ может быть, например, таким: а передаются воздействия с помощью создания различных механических напряжений в разных частях этого элемента. Где-то потянули “на три ньютона” (условно), а здесь, в другом месте, одновременно, – надавили с другой силой. Комбинацию сил, приложенных к разным участкам, создаёт механизм замка, но при этом механизм можно так устроить, что верная комбинация никак не следует из его структуры (потому что комбинация “хранится” не в механизме замка, а в структуре того самого метаматериального элемента). В общем, да, остаётся возможность исследования ключевого элемента такого замка, но его уже можно так запрятать, что сканеру будет не дотянуться.

Схема, кстати, “с теоретической точки зрения” аналогична, например, оптоэлектронным развязкам, применяемым в системах специальной связи.

Существовало немало технологий, которые, с развитием технического прогресса, вдруг переставали решать возложенные на них задачи, несмотря на то, что раньше вроде бы неплохо с этими задачами справлялись. Хрестоматийный пример, хорошо известный из военной истории: классический металлический доспех, служивший сотни лет, но вдруг ставший бесполезным на поле боя, после появления доступного лёгкого огнестрельного оружия. Или, скажем, какие-нибудь старые криптосистемы (хоть бы известные механические шифровальные машины), которые при наличии, в качестве вычислителя, даже современного смартфона раскрываются за секунды. Или – парусный торговый флот. Паровозы какие-нибудь. В общем – примеров много.

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

Технологии развиваются. Благодаря всё тем же доступным компьютерам, копии ключей нынче научились делать просто по фотографиям. То есть, оказывается, достаточно сфотографировать связку ключей, лежащих себе где-нибудь на столе, с помощью мощного объектива с большого расстояния – чтобы тут же, практически за какие-то минуты, используя специальную машинку с программным управлением, изготовить отличную копию ключа. Копия, кстати, хороша тем, что замок открывается штатным способом, поэтому позже оказывается чрезвычайно сложным доказать, что кто-то куда-то там проник.

Но дело обстоит ещё интереснее. Подавляющее большинство современных механических замков устроены, мягко говоря, весьма просто. Даже неполная информация о ключе, о конфигурации деталей конкретного замка, помогает быстро и без разрушения замок открыть с помощью отмычек. Сейчас даже сформировался такой вид интеллектуального спорта, когда замки (без, понятно, “родных ключей”) опытные энтузиасты открывают на скорость, просто ради того, чтобы открыть. Прогресс в этом спортивном хобби – он только подчёркивает то, насколько плохо защищены замки.

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

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

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

Как только подобные электронные отмычки подешевеют, а это должно произойти вот буквально в ближайшие годы, обычные механические замки, все подряд, зараз перейдут в разряд бесполезных технологий. Большинство из современных замков специалист и так открывает за секунды, используя самое простое оборудование (вспомните, хотя бы, нашумевший после обнародования метод, известный в Сети как lock bumping). Развитие электроники и программного обеспечения приведёт к тому, что открыть можно будет практически любой современный механический замок одним универсальным устройством, в автоматическом режиме, незадумываясь (последнее очень важно).

Какие замки станут использовать в будущем? Ведь понятно, что замки – нужны. Наверное, очевидное решение: замена замков на электронные, с микрочипами внутри и электрическим приводом засова. Электронный замок исследовать сложнее. Если приплюсовать сюда электронный ключ, который тоже содержит чип, то получается довольно сложная для аналитика система. Электрические цепи и всякие там дополнительные детали, открывающие засов, также можно хорошо защитить от “атакующих” – речь же идёт о неразрушающем отпирании замка. Но возникают известные проблемы: для работы замку (или ключу) требуется электричество, а система получается непростой, “многофакторной”, и, поэтому, возможно, не самой надёжной.

Если вернуться к упомянутой в начале заметки истории с доспехами, то окажется, что технический прогресс всё же помог обеим сторонам: появилась броня нового поколения и бронежилет сейчас – это стандартный элемент экипировки. Новые технологии помогут развивать и механические замки, тем более, что направление развития – известно. Например, в замках будущего могут появиться некие “обманки”, направленные на то, чтобы сбить с толку автоматический измеритель. Можно устроить замок так, что даже доступ в замочную скважину, для измерения параметров, потребует использования специального жала ключа (собственно, уже сейчас для замков с хорошей секретностью в списке основных проблем, стоящих перед взломщиком, получение правильной заготовки для ключа).

Схему с несколькими взаимосвязанными подсистемами защиты вообще можно развивать дальше, привлекая новые параметры физического ключа: например, рабочая часть ключа изготовлена из нескольких материалов, обладающих определёнными механическими свойствами; для успешного открывания замка требуется не только совпадение формы ключа, но и совпадение расположения участков из этих разных материалов. (Такие замки, кстати, уже есть.)

Также напрашиваются совсем хитрые решения с многоступенчатым доступом к разным элементам замка, использующие в качестве секрета промежутки времени. То есть, в данной схеме для анализа следующего участка, после того, как открыт предыдущий – просто нет времени; при этом, определить нужную последовательность и вычислить интервалы времени для каждого этапа – довольно сложно, автоматический измеритель вряд ли справится. Реализуется механически. В теории, можно так сделать, что вообще не получится открыть за разумный минимум попыток, не имея оригинального ключа (грубо говоря, примером тут является хорошо известная схема с одновременным поворотом двух ключей, ну или двух “частей” одного). Есть ли такие замки уже? Вряд ли.

Вот.

Какие ещё идеи?