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

Получается непрерывная серия записок про TLS и связанные технологии, но, тем не менее, продолжу. Добавил на dxdt.ru поддержку технологии под названием HPKP – HTTP Public Key Pinning. Key Pinning – это привязывание публичного ключа к сетевому ресурсу (по имени или по адресу) на стороне клиента. Принцип хорошо известен из практики использования SSH: здесь отпечатки, идентифицирующие серверы, при первом контакте сохраняются на клиенте; в дальнейшем, изменение отпечатка позволит обнаружить возможную подмену ключей в рамках атаки “человек посередине”. Для HTTP предложена технология (RFC 7469), базирующаяся на той же идее.

Веб-сервер передаёт специальное поле в составе заголовков HTTP. Поле содержит отпечатки (значение хеш-функции) публичных ключей, которые используются данным сервером при установлении TLS-соединения, а также время, в течение которого клиенту следует помнить отпечатки. Браузер (то есть, клиент HTTPS), впервые обнаружив отпечатки ключей, запоминает их. При следующих обращениях к данному ресурсу – отпечатки сверяются с переданными ключами: если обнаружено расхождение, то браузер не устанавливает соединение и выдаёт предупреждение системы безопасности. HPKP поддерживается, например, в Chrome и Firefox.

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

Посмотрим на реализацию подробнее, на примере dxdt.ru:

$ wget -S -O /dev/null https://dxdt.ru/ 2>&1 | grep ‘Public-Key-Pins:’ | tr -s ‘ ‘ | sed ‘s/\;/\;\n/g’

Public-Key-Pins: pin-sha256=”WXeGHAmPHRPwX7CbyIUCQm9mtStbVAZR2LOvTAAQKNg=”;
pin-sha256=”dj2qz8mxs8NSpJdISrUPRfL86ZGu3QNkJm4hL+opE0o=”;
pin-sha256=”nq9/zIb/QKb+tHd1ZU5keAYkYzrA8zx7tMmVtDDNG0M=”;
pin-sha256=”kkwURRddFrj4gRH7ILMp/Fqrvl6kfO4o2ekBOmiP6B0=”;
max-age=270127;

Поле HPKP называется Public-Key-Pins и, в нашем примере, содержит четыре значения pin-sha256 – это и есть отпечатки ключей (значение SHA-256 от публичного ключа, взятое в Base64). Почему их четыре? Потому что на dxdt.ru поддерживается два типа подписей: ECDSA и RSA, соответственно, нужно публиковать отпечатки для каждого из них; кроме того, стандарт требует указания как минимум одного “запасного ключа”, который отсутствует в цепочке валидации – я решил опубликовать по запасному ключу для каждого типа подписи. Итого: четыре отпечатка. Дополнительные отпечатки, очевидно, требуются для того, чтобы можно было поменять ключи без потери доступности сайта.

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

Параметр max-age – определяет (в секундах) время, в течение которого браузер должен сохранять отпечатки. Я, пока что, установил довольно осторожное значение: около трёх суток.

Кроме того, поле Public-Key-Pins позволяет использовать ещё пару параметров: includeSubdomains – это флаг, распространяющий действие отпечатков на поддомены; report-uri – адрес, на который браузер будет передавать сообщения об ошибках. Последний параметр особенно интересен. Он позволяет поднять сервер, который будет получать сообщения от клиентских браузеров, которые натолкнулись на ошибки в работе HPKP – это позволяет обнаруживать атаки “человек посередине”, что называется, в дикой природе. Сообщение содержит детали контекста, в котором возникла ошибка. Эту функцию уже реализует Google Chrome. Естественно, для приёма сообщений нужен отдельный домен. Создание такой точки приёма для dxdt.ru – следующий шаг: нужно выделить сервер и запрограммировать обработчик сообщений.

Addon:

Как получить отпечатки ключей? Достаточно просто, если воспользоваться OpenSSL (я использовал файлы секретных ключей).

Для RSA:

openssl rsa -pubout -in rsa-private.pem -outform DER | openssl dgst -sha256 -binary | openssl enc -base64

Для ECDSA:

openssl ec -pubout -in ec-private.pem -outform DER | openssl dgst -sha256 -binary | openssl enc -base64

В OpenSSL теперь будет ГОСТ (2012) для TLS:

“Специалисты Технического центра Интернет (ТЦИ) достигли договоренностей о включении поддержки российских криптографических алгоритмов цифровой электронной подписи и хеширования 2012 года ГОСТ Р 34.10-2012 и ГОСТ Р 34-11.2012.”

Силами Дмитрия Белявского. Замечательно. (Соответствующий commit в Git OpenSSL.)

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

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

Отдельная полезная функция – известно, где находится говорящий в данный момент. Такая замечательная система смогла бы отвечать на следующие запросы: “где находятся пользователи, обсуждающие пролёт НЛО?”. “Пролёт НЛО” отдельно описывается в виде “семантического фильтра”, с набором слов и грамматических конструкций. Естественно, НЛО можно заменить на другие интересные объекты и явления.

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

Описание я планирую дополнять, потому что, несмотря на объём, охвачены ещё не все аспекты, которые хотелось бы рассмотреть. Сейчас в деталях рассмотрены такие ключевые моменты, как установление соединения (Handshake) и логика построения обмена сообщениями – это основа основ TLS. В ближайших планах: раздел, разбирающий современные шифры (в различных режимах работы), пояснения про использование криптографии на эллиптических кривых. Вероятно, будут исходники на С, поясняющие некоторые моменты реализаций. Конечно, нужен структурный путеводитель по RFC, имеющим отношение к TLS (их великое множество). Для того, чтобы получился полноценный тематический сайт я выделил проекту отдельный адрес: https://tls.dxdt.ru/. (Правда, пока там многое нужно оформить.)

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

Сам текст:

Ключи, шифры, сообщения: как работает TLS

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

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

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

Понятно, что можно попробовать связать аккаунты на основе IP-адресов, но, при существующем распространении NAT, за одним адресом могут оказаться сотни различных пользователей. Если игра использует специальный клиент, идентификатором может послужить некий уникальный номер клиентской программы, но ведь и компьютер может быть общим, так что тоже возникает погрешность. А вот изменить поведение в игре – игроку крайне сложно, скорее, невозможно, если вести речь не о крупных чисто игровых действиях, а о базовых интерактивных элементах: о манере передвижения мышки, управления движением персонажа, использования меню и настроек в игре.

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

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

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

На сервере, где расположен nic.ru, установлен валидный сертификат с расширенной проверкой (EV). Однако если зайти на сайт при помощи браузера Chrome (42.0.2311.90 – актуальная на момент написания заметки версия), работающего в среде операционной системы Windows (версии 8.1, например), то в адресной строке браузера появляется предупреждение о том, что сайт использует устаревшие технологии безопасности. Выглядит это так:

Естественно, ожидается, что корректно установленный EV-сертификат приведёт к другому эффекту, отобразив “доверенную” адресную строку. Так происходит в браузере Internet Explorer 10, на той же тестовой машине:

А если воспользоваться браузером Mozilla Firefox, то эффект тоже положительный:

Впрочем, положительный эффект в Firefox имеет под собой другую почву, нежели случай IE. Что происходит, почему браузеры ведут себя именно так?

Посмотрим на набор сертификатов, возвращаемых сервером. Здесь есть три сертификата: серверный и два промежуточных; вот их свойства, указанные в полях Subject (s, предмет сертификации) и Issuer (i, удостоверяющая сторона):

0.
s:O=JSC ‘RU-CENTER’/OU=Project Department/CN=www.nic.ru
i:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4

1.
s:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4
i:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority

2.
s:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority
i:O=Equifax/OU=Equifax Secure Certificate Authority

(Имя nic.ru без www. указано в расширении SAN сертификата, так что адреса на скриншотах – корректны.)

Проблемным является сертификат под номером 2 (выпущенный для GeoTrust Primary Certification Authority), так как он использует SHA-1 в составе алгоритма генерации подписи. Согласно политике Google Chrome, если в цепочку сертификатов (исключая корень) входит хотя бы один, подписанный с использованием SHA-1, то в адресной строке выводится предупреждение. Посмотрим на цепочку:

Всё сходится – промежуточный сертификат с SHA-1 входит в цепочку сразу после корня. (Обратите, кстати, внимание на то, что корень обозначен как GeoTrust, хотя сам корневой сертификат содержит название Equifax, в чём можно убедиться, если посмотреть внутрь его полей. Это следы маркетинга: бизнес по продаже цифровых сертификатов Equifax был продан компании, оказывающей эти услуги под брендом GeoTrust.) IE использует тот же набор корней, однако политика этого браузера позволяет даже EV-сертификатам быть подписанным по цепочке, включающей SHA-1, поэтому здесь всё хорошо.

А вот Firefox использует собственный набор корней, поэтому цепочка валидации тут иная:

Firefox содержит доверенный корень, обозначенный как GeoTrust Primary Certification Authority, от которого подписан промежуточный сертификат GeoTrust EV SSL CA – G4. То есть, те же сертификаты уже выстраиваются в цепочку, которая не содержит SHA-1, поэтому данная ситуация не может вызвать предупреждения, даже если бы такое предупреждение поддерживалось Firefox. Аналогично устроен и Google Chrome под Linux – там тоже встроен корень, позволяющий избежать использования промежуточного сертификата с SHA-1.

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

Что нужно делать веб-сайтам? Нужно перевыпускать сертификат в цепочке, которая не использует SHA-1.

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

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

Санкции, предписанные федеральным правительством штатовским ИТ-компаниям, привязаны к определённым территориям. Не все сервисы, устройства и услуги можно выключить с высокой точностью, основываясь на геопривязке. Но многие – можно. Например:

доменные имена и IP-адреса – для них указываются контактные данные администратора (домена или блока IP-адресов), в которых, обычно, прописана страна и регион (хотя, в некоторых случаях, эти данные могут быть неверны). Регистрация домена может быть прекращена, а имя, соответственно, удалено или заблокировано;

некоторые операционные системы – например, Microsoft Windows ходят за обновлениями на серверы Microsoft, а идентификатор установки этой ОС имеет региональную привязку (по данным от магазинов и компаний-интеграторов). С уверенностью говорить нельзя, но, теоретически, ОС могут быть заблокированы с помощью раздачи некоторого специального обновления, срабатывающего только на некоторой выборке идентификаторов (лицензионных ключей). Естественно, в правильно настроенной коропативной среде такие обновления сами могут быть предварительно заблокированы, но наивно полагать, что такие среды встречаются повсеместно;

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

часть операторского телекоммуникационного оборудования (и в сетях GSM, и в других сетях передачи данных) – данные о географии установок известны производителям от региональных дистрибьюторов. Отключить оборудование можно через имеющиеся каналы технологического управления, а в случае их предварительной блокировки, через уязвимости, которые, наверняка, имеются в достаточном количестве;

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

Хуже всего, что, в теории, подобные блокировки могут коснуться и промышленного оборудования: современные АСУ (SCADA и т.д.), к сожалению, также не отличаются автономностью, а поэтому могут быть заблокированы дистанционно, по практически официальным каналам управления и обновления.

В общем, есть где развернуться.

(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в DNSSEC. Думаю, что описание заслуживает публикации на dxdt.ru – потому что до сих пор нередко путают ключи, зоны, цепочки делегирования и прочие важные моменты.)

Посмотрим на то, как используются ключи DNSSEC, взяв для примера зону .org. Предположим, что мы справшиваем SOA-запись для .org у корневого сервера. Тогда, вместе с адресами NS-ов домена org, если последний делегирован безопасно, то есть, с DNSSEC, мы получим от корневого сервера DS-запись (или несколько – сейчас, например, их для .org две) и RRSIG-запись для DS (важно – именно для DS). То есть, главная интересующая нас подпись содержится в корне, это RRSIG over DS (RRSIG от DS). Напомню, что DS-запись содержит значение хэш-функции ключа, относящегося к делегируемой зоне (то есть, в случае нашего примера, к .org). Подпись RRSIG сгенерирована при помощи корневого ZSK (Zone Signing Key, ключа подписи зоны), который опубликован в корневой зоне, и его нужно будет оттуда получить, чтобы проверить подпись на DS. (Ключ также может уже находиться в кэше резолвера, тогда запрашивать его у корневых серверов не нужно.)

В дальнейшем, информацию, полученную с сервера имён (NS) домена org, мы проверяем ключами, которые опубликованы в этой же зоне (в .org). То есть, RRSIG-и из данной зоны проверяются ключами, которые в той же зоне и расположены. Для связывания ключей из разных зон в цепочку доверия служат DS-записи, которые также подписываются.

Посмотрим чуть ближе на реальное устройство DNSSEC для .org, как всё выглядит сейчас:

1.

В корне (в корневой зоне) мы видим два ключа (я буду их обозначать реальными идентификаторами, которые я взял из DNS) – 22603 (ZSK) и 19036 (KSK – кстати, не менялся с 2010 года, потому что забыли придумать, как его поменять). Для ключа 22603 в корневой зоне есть RRSIG, сгенерированная от ключа 19036. 19036 – это и есть тот самый главный, корневой, рутовый KSK, открытая часть которого изначально находится у нас в резолвере (пусть ключ и опубликован в DNS, но в резолвер он должен попасть каким-нибудь другим доверенным путём, не черезе DNS). После того, как мы проверили RRSIG от ключа 22603 этой открытой частью ключа KSK (19036) и всё сошлось, мы добавляем ключ 22603 в доверенные ключи. И можем пойти дальше.

2.

В корне же мы видим DS-записи для ORG, а также RRSIG для них. Подпись (RRSIG over DS) сделана от ключа 22603 (то есть, от ZSK, см. выше). Ключ 22603 мы только что добавили в доверенные. Проверяем подпись на DS-записи, если всё сошлось, то можем пойти дальше, записав себе значение DS.

3.

На серверах, поддерживающих .org, мы видим четыре ключа – 9795, 21366 (эти два – KSK) и 60764, 11112 (а эти два – ZSK; KSK от ZSK отличаются значением одного бита в поле типа ключа). Хэш от ключа 21366 соответствует значению DS-записи, опубликованной в корне (см. выше). Эту запись мы только что (ну или некоторое время назад, см. TTL) получили от корневого сервера, вместе с подписью, которую проверили – значит, DS-у доверяем.

4.

На серверах .org мы также видим записи (их сейчас три) RRSIG для набора DNSKEY. Эти три записи RRSIG сгенерированы от трёх ключей: 9795, 21366 и 11112 – обратите внимание, каждая из этих RRSIG подписывает все ключи, опубликованные в зоне (ключи публикуются в записях DNSKEY). То есть, у нас четыре ключа подписаны при помощи трёх других. Один из этих подписывающих ключей – 21366 – соответствует DS-записи, полученной из корня, поэтому мы можем добавить его в список доверенных ключей. Теперь записям, подписанным этим ключом, мы тоже будем доверять. После того, как мы убедились, что подпись от ключа 21366, сделанная для RRSIG DNSKEY в зоне .org, – валидная, мы добавляем и три других ключа (9795, 11112, 60764) в список доверенных. Почему? Потому что RRSIG over DNSKEY удостоверяет и их тоже – она для всех ключей зоны общая.

5.

Итак, мы решили получить SOA-запись (это главная запись в любой DNS-зоне) от .org и проверить её. Нет ничего проще: получаем SOA, вместе с ней приходит RRSIG, сгенерированная от ключа 11112, этот ключ есть у нас в списке доверенных, поэтому проверяем подпись – если сходится, то верим данным из SOA-записи. (Аналогично – для А-записей и для прочих.)

Обратите внимание, что мы не проверяли подписи на адресах NS-ов (серверов имён .org) – этого и не нужно делать, если только мы не хотим проверить именно значения NS-ов. Хитрость в том, что в DNSSEC не имеет значения, откуда были получены подписанные данные – с легитимных серверов или ещё откуда-нибудь: главное, чтобы подписи сходились.

Резюме: информацию, получаемую с серверов .org, мы проверяем ключами, полученными с тех же серверов, а вот убедиться, что это правильные ключи, нам позволяет подпись (RRSIG over DS) из корневой зоны.

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

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

Бэкдор должен обладать свойством “отрицаемости”: то есть, в случае его обнаружения, разработчики должны иметь возможность аргументированно “доказать”, что никакого бэкдора и нет, а это всё “непреднамеренная ошибка”, “особенность протокола” или ещё что-то подобное.

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

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

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

Конечно, большинство практических бэкдоров лишены некоторых из перечисленных выше свойств. Но где-то могут быть и идеальные представители. Просто их не так легко обнаружить.