Угрозы доверия(ю)
Павел ХрамцовОсновной тренд современного развития технологий – потеря доверия участников взаимодействия друг к другу. И это принципиальный момент, т.к. большинство современных технологий базируются именно на доверии. Собственно, весь Интернет – это, изначально, одно сплошное доверие. Еще один важный момент в развитии современных коммуникационных технологий – это защита адресов и контактов. Разберем несколько примеров, которые подтверждают приведенные выше тезисы. Как это ни выглядит парадоксальным, но и мир off-line, и мир on-line здесь во многом похожи.
Спекуляции – это плохо, или За что боролись, на то и напоролись!
Вначале 2018 года были опубликованы и широко обсуждались аппаратные уязвимости современных микропроцессоров, используемые в Spectre и Meldown.
Не вдаваясь глубоко в суть проблемы, можно констатировать, что ускорение производительности современных процессоров за счет спекулятивных вычислений привело к появлению аппаратной уязвимости, которая не может быть устранена без снижения производительности.
Но для начала разберемся с термином «спекулятивные вычисления». В 1974 году в журнале EEE Journal of Solid State Circuits группа авторов во главе с Робертом Деннардом (Robert H. Dennard) опубликовала статью «Design of Ion-Implanted MOSFETswith Very Small Physical Dimensions». Из статьи следовало, что миниатюризация элементной базы приводит к повышению быстродействия и снижению электропотребления. Данный закон получил название закона Деннарда. Этот закон дал физическое обоснование другому закону – закону Мура. Фактически, работа Деннарда и его коллег задала направление развития вычислительной техники на 30 лет вперед.
Однаков 2005-2007 годах закон Деннарда перестал работать. Миниатюризация уперлась в физические ограничения. «Разогнать» обычный одноядерный процессор быстрее 4ГГц не удавалось. Быстродействие не росло, и появились архитектуры со многими ядрами.
Но еще до появления многоядерных архитектур была реализована возможность параллельных вычислений на аппаратном уровне, собственно закон Деннарда и позволял это сделать. Среди способов аппаратной реализации параллельных вычислений можно выделить внеочередное исполнение команд и спекулятивные вычисления. При внеочередном исполнении команд команды исполняются в момент, когда имеется возможность их выполнить, а не по порядку, установленному в программе. Это означает, что процессор может выполнить некоторые команды, результаты которых могут и не понадобиться в будущем. Но если результат понадобится, то он уже будет готов к этому моменту.
Спекулятивное исполнение – это исполнение команд, результаты которых могут потребоваться в будущем с высокой вероятностью. И в первом, и во втором случае происходят множественные обращения к страницам памяти. Для ускорения операций отображения виртуальной памяти в физическую существует специальный механизм кэширования такого соответствия. Уязвимости, которые эксплуатируют Spectre и Metdown, связаны с эксплуатацией особенности работы этого механизма. Но собственно существование этого механизма и обеспечивает повышение быстродействия. Отказ от него (механизма) приводит к снижению скорости вычислений. Это все прекрасно понимали, когда проектировали процессоры с возможностями измененного порядка выполнения команд и спекулятивным вычислениями. Теоретически уязвимость могла быть использована еще лет десять тому назад. Но попробовать реализовать уязвимость решили только 2017 году.
О чем это говорит? Разделение и защита образов процессов — это давно установленное правило. Защита области ядра – это тоже давно установленное правило. Все это принято называть безопасностью. Но безопасность бывает разная. Одно дело защита от непреднамеренных ошибок — safety— и другое дело — защита от преднамеренного воздействия — security. Большинство современных компьютерных технологий разрабатывалось в эпоху действия парадигмы SAFETY. Анализ аппаратных платформ на предмет фундаментальных уязвимостей переводит нас в эпоху SECURITY. И еще одно: и Meltdown, и Spectre эксплуатируют уязвимость, основанную на чтении адреса. Возможно, это совпадение, но ниже мы убедимся, что современный тренд безопасности – это защита адресов и контактов.
Феномен Telegram
13 апреля 2018 года Таганский суд Москвы вынес решение по иску Роскомнадзора немедленной блокировке мессенджера Telegram. С этого момента началась эпопея по обходу ограничения «доступа к информационным системам и (или) программам для электронных вычислительных машин, которые предназначены и (или) используются для приема, передачи, доставки и (или) обработки электронных сообщений пользователей сети «Интернет» и функционирование которых обеспечивается Telegram Messenger Limited Liability Partnership».
В результате выполнения решения суда по установке ограничений доступа со стороны Роскомнадзора в «черные списки» попали десятки миллионов IP-адресов. В том числе, например, адреса облачных сервисов Amazon и Digital Ocean. Формально решение суда, чтобы ни говорила сетевая общественность, Роскомнадзор выполнил. Ограничение доступа, если подходить формально к букве постановления суда, было реализовано и действует до сих пор. Однако самым любопытным во всей этой истории является совсем не это. Суд мотивировал свое решение отказом Telegram предоставить ключи для чтения контента. А противоборство между надзорным ведомством и Telegram развернулось вокруг маскирования адресной информации, т.е. адресов серверовTelegram.
Среди множества технологий такого маскирования следует выделить технологию репликации Telegram proxy-серверов (MTProto Proxy). Собственно, сами серверы Telegram никуда не переезжают. Авария в голландских электросетях только подтвердила этот факт. Разработчики Telegram предложили пользователям мессенджера специализированное программное обеспечение, которое может быть установлено в сети любого ISP.
Таким образом, учитывая формулировку суда, установка MTProto Proxy провоцирует блокировку сетей любого провайдера. Именно по этой причине под ограничения доступа и попали Amazon с Digital Ocean. Фактически, Telegram запустил процесс построения добровольного «ботнета». В этой связи борьба за ключи шифрования перешла в плоскость борьбы за реальные адреса, которые использует сервис. Telegram защищает/маскирует свои адреса и тем самым сохраняет работоспособность сервиса.
Это странное слово – «GDPR»
Теперь от адресов программ перейдем к данным, которые позволяют однозначно идентифицировать персону, то бишь обычных людей. К защите персональных данных, в том числе и персональных контактов. С 25 мая 2018 года в силу вступила директива Европейского союза по защите данных (General Data Protection Regulation). В основном она касается правил обработки персональных данных граждан Европейского Союза. Особое значение этой директиве придают следующие особенности: она носит экстерриториальный характер, она предполагает право на забвение и она предполагает огромные штрафы (до 20 000 000 евро или 4% годового оборота) для любой компании в мире, которая будет замечена в нарушении Директивы. Дилемма, которая возникает при реализации GDPR, – это противоречие между требованиями правоохранителей различных стран мира по поводу свободного доступа к персональным данным физических лиц с целью противодействия деяниям, угрожающим общественной безопасности, и защитой этих самых персональных данных от доступа к ним неограниченного круга лиц. На самом деле, национальных законов, защищающих персональные данные граждан, почти столько же, сколько стран. В рамках этих законов доступ к данным так или иначе отрегулирован.
Получить персональные данные администратора домена в .ru можно, например, либо по решению суда, либо в соответствии с законом об «Об оперативно-розыскной деятельности» от 12.08.1995 № 144-ФЗ. Для того, чтобы оценить влияние GDPR на управление пространством доменных имен, достаточно сказать, что половина заседаний секции очередной конференции ICANN8 была посвящена одному вопросу – как жить в этих условиях дальше. Однако, по порядку.
Семь лет назад организация NORC at the University of Chicago по контракту с ICANN провела анализ достоверности данных WHOIS. Исследовалась возможность получения обратной связи от администратора домена, а также достоверность предоставляемой информации администратором домена для хранения в реестре. Исследовались в основном домены верхнего уровня общего назначения .com, .net,.org, .biz, .info (суммарно чуть более 98% от общего числа доменов в выборке).
Было установлено, что корректно данные администратора домена были указаны только в 23,9% случаях. Абсолютная невозможность связаться с администратором домена была выявлена только в 7,8% случаев. Для понимания общей картины эти цифры требуют разъяснения. Регистрация в доменах, которые исследовала NORC, носит уведомительный характер, собственно, так же, как и в российских национальных доменах .ru и .рф. Это значит, что необходимым условием регистрации и обслуживания домена является возможность контакта регистратора и администратора домена.
Остальные параметры, хоть и являются важными, и прописаны в договоре между регистратором и администратором домена, являются опционными, т.е. обслуживание клиента на том основании, что эти параметры отсутствуют, не прекращается. Невозможность контакта была оценена исследователями в величину, равную менее 8% от общего количества исследованных доменов, что является по любым меркам довольно малой величиной.
Тем не менее, точность данных WHOIS была признана катастрофически недостаточной. Данных не хватало для идентификации администраторов доменов, т.е. для надежного установления адреса администратора. Понятно, что это нужно только для поддержки «безопасности и стабильности» работы системы, т.е. прямого отношения к технологии DNS не имеет. О чем и было замечено в отчете Комитета советников ICANN по безопасности и стабильности (SAC058) от 27 марта 2013 года.
С момента появления этого отчета в IETF была начата разработка нового протокола Registration Data Access Protocol (RDAP), который должен был заменить старый протокол WHOIS. Новый протокол обеспечивал также структуризацию данных и простоту автоматической обработки запросов. В марте 2015 года он был утвержден в качестве стандарта. Его отличие от традиционного WHOIS в формате запросов и ответов (это RESTFul протокол) и детализации персональных данных администраторов доменов. После опубликования протокола обязательное требование поддержки RDAP появляется в перезаключаемых контрактах gTLD и в программе new gTLD12. Все аккредитованные вICANN регистраторы теперь обязаны поддерживать этот протокол и обеспечивать полноту данных, которые передаются в реестры. Эти же данные попадают в резервные файлы data escrow. Кроме того, все эти данные могут быть доступны в публично в сервисах реестра (Registration Data Directory Services). Никакого ограничения или особых условий доступа в контрактах прописано не было.
Параллельнос этой историей в ICANN задумались об аккредитации privacy и proxy-сервисов, которые могут использоваться для сокрытия контактов администраторов доменов. Данный пункт предполагалось включить во все контракты регистраторов. При обсуждениях этой политики в рабочих группах все уперлось в раскрытие информации по запросам правоохранительных органов. Кроме того, с 1 мая 2018 года предполагалось начать новые регистрации в формат «толстого» реестра для доменов .com, .net и .job. Это тоже важно для понимания значения GDPR. Все дело в том, что реестры доменов до настоящего времени в зависимости от объема и типа хранящихся в них данных делят на «толстые» и «тонкие». «Тонкий реестр хранит только техническую информацию о домене (домен, регистратор, даты начала и окончания регистрации и серверы, на которых домен делегирован). Данных об администраторе домена в «тонком» реестре не хранится. В этом случае все данные об администраторе домена хранятся у регистратора. «Толстый» реестр хранит не только технические данные домена, но и данные его администратора. Перевод реестров из формата «тонкого» реестра в формат «толстого» реестра предполагает, что все данные администраторов домена регистратор передаст третьей стороне – реестру, а также оператору резервной копии реестра (dataescrow).
И еще. В январе 2018 года ICANN в очередной раз вернулся к вопросу применения правил трансляции и транслитерации контактной информации для сервиса RDDS и протокола RDAP.
Таким образом, можно констатировать, что с одной стороны ICANN стремилась к повышению точности контактной информации в реестрах, а с другой, доступ к этой информации никаким общим документом не описывался. Появление GDPR привело к тому, что 17 мая 2018 года ICANN вынуждена была выпустить «Временную спецификацию для регистрационных данных gTLD», которая вступила в силу с 25 мая 2018 года (начало действия GDPR). Издание этого документа не принесло каких-либо открытий. Например, многие рекомендации Временной спецификации в части отображения персональных данных в WHOIS практически дословно повторяют правила регистрации в доменах .ru и .рф. Также для целей анонимизации данных предлагается процедура хеширования персональных данных, которая во многом похожа на ту, что используется в проекте «Нетоскоп» Координационного Центра национального домена сети Интернет.
Данная история – это демонстрация двух основных тенденций развития Интернета. С одной стороны, защита частной жизни, а с другой – защита общественной безопасности. И ключевую роль в этом конфликте играют адреса и контакты, а точнее, их защита и правила раскрытия.