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

В DARPA Robotics Challenge 2015, соревнованиях роботов, имитирующих работу в ситуации техногенной катастрофы, победил робот DRC-HUBO южнокорейской команды KAIST. Это робот “гуманоидной”, точнее – андроидной, схемы, достаточно точно повторяющей человека. Это, впрочем, не помешало ему выиграть.

Робот RoboSimian NASA, один из немногих неандроидных вариантов, представленных в финале соревнований, оказался на пятом месте из 23 команд (какие-то очки, при этом, получили только 19 команд).

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

В восприятии DARPA Robotics Challenge – многое зависит от того, как вы относитесь к перспективе наполнения окружающей действительности бегающими и прыгающими автономными роботами, которых, конечно, вооружат не только лобзиками и шуруповёртами, как в этих соревнованиях. В зависимости от точки зрения, робот-андроид, медленно и не очень уверенно пробиравшийся на своих механических ногах сквозь небольшой завал из строительных блоков, а в самом конце вояжа рухнувший с размаху оземь, отключившись и потеряв навесные агрегаты, может и опечалить, и ободрить – мол, не так уж и близко идти технологиям до уверенного передвижения перебежками между разрушенными зданиями. Впрочем, похоже, что близко. Очень близко.

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

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

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

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

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

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

На фотографии – F-35, в “не-Cтелс” режиме, с вооружением на внешней подвеске, во время испытаний несимметричной конфигурации.

Фото Lockheed Martin отсюда.

Занятно, что в Microsoft уже некоторое время используют неподходящий SSL-сертификат для windows.microsoft.com: предъявляемый сервером сертификат выпущен для *.windows.microsoft.com, а это имя, естественно, не подходит, так как работает только для четвёртого уровня. Такая вот неразбериха.

В свете недавно выявленной уязвимости TLS – Logjam возник интерес к отличиям различных версий и реализаций алгоритма Диффи-Хеллмана. Вообще, современное состояние дел с криптографией в Интернете таково, что вместо небольшого набора простых и понятных протоколов, используется огромная куча спецификаций, в которых, по историческим причинам, наворочено много разных тонкостей. Одна из таких тонкостей – отличие шифронаборов, содержащих в своём обозначении DH, от шифронаборов с DHE (добавлен суффикс E).

DH – обозначает Диффи-Хеллмана. E – Ephemeral (почему-то сейчас в переводе используют “эфемерный”, хотя лучше подошло бы “краткосрочный” или “единовременный”). Обычно пишут, что вариант DH – не обладает прогрессивной секретностью (то есть, записанный ранее трафик можно раскрыть через какое-то время, если удалось получить секретный ключ сервера), а DHE – обладает. В чём же различия?

Вспомним, что алгоритм Диффи-Хеллмана использует следующие общие параметры: P – модуль (большое простое число, задающее группу, в которой производятся вычисления – (mod P), дальше это обозначение опускаю); G – “генератор” (число, элемент выбранной группы). Это публичные параметры. Условный “открытый ключ” сервера образуется при помощи вычисления A = G^a, где a – секретная часть ключа (экспонента). Клиент выбирает своё значение b, вычисляет B = G^b и передаёт на сервер. Для получения общего секрета сервер и клиент вычисляют, соответственно, s = B^a = (G^b)^a = G^(ba) и s = A^b = (G^a)^b = G^(ab). Обратите внимание на параметры со стороны сервера: P,G,A.

В случае реализации DH предполагается, что параметры сервера (P,G,A) – заранее подписаны неким внешним ключом, что позволяет клиенту проверить их подлинность. Это означает, что параметры фиксированы от сессии к сессии, а сервер может использовать только одну экспоненту (a), которая соответствует G^a = A. Самое важное, что фиксируется именно экспонента a – сервер должен её сохранять в долговременной памяти, так как она связана с открытой частью ключа A. Есть старые рекомендации, предписывающие включать параметры DH в состав сертификата. Впрочем, на практике такие вещи не встречаются. Понятно, что если секретные ключи сервера, а именно – значение a, оказались раскрыты, то они позволят вычислить сеансовые ключи (s) для всех записанных сессий, так как теперь аналитику известна величина a и он может определить s = B^a = G^(ab) (значение B – сохранено в записи трафика, так как его в открытом виде передаёт клиент). Очевидно, что точно так же можно раскрыть трафик, если аналитику известен секретный параметр на стороне клиента (b) – например, этот параметр утёк из браузера.

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

В случае DHE – как минимум a и G^a = A – генерируются сервером заново для каждой сессии, и, как считается, значения не сохраняются на долгое время. А для того, чтобы клиент мог провести аутентификацию параметров, они подписываются ключом сервера (тот же ключ используется в SSL-сертификате). Это нормальный современный вариант использования алгоритма Диффи-Хеллмана в TLS.

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

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

Чтобы не пропадал домен pwd4.me и выпущенный для него SSL-сертификат – сделал там одностраничный генератор паролей (который, хоть и использует Web Crypto API, – а поэтому работает только в современных браузерах, – но может быть признан лишь “учебным”). Кстати, HTTPS в подобных сервисах необходим, чтобы обезопасить пользователей от инъекции Javascript-кода.

(Update: 11/05/2026 – сервис более не доступен.)

В продолжение истории об уязвимости в протоколе TLS, получившей название Logjam. Использование уязвимости базируется на нестойких параметрах алгоритма Диффи-Хеллмана – малого модуля, длиной в 512 бит (так называемый “экспортный вариант” параметров алгоритма). Для того, чтобы успешно применить эту уязвимость в реальности, требуется совпадение нескольких факторов:

1) атакующий должен иметь возможность активно перехватывать TLS-соединение. То есть, между клиентом и сервером должен находиться активный перехватывающий узел, не просто умеющий делать DPI, но работающий с весьма сложной логикой: нужно находить в TCP-трафике сообщения TLS, декодировать их, “завешивать” сессии, подменять информацию в пакетах;

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

3) атакуемый TLS-сервер должен поддерживать заведомо устаревшие “экспортные параметры” алгоритма Диффи-Хеллмана.

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

Что, конечно, не отменяет пользы от привлечения внимания к дефекту протокола. Есть шанс, что в TLS 1.3 что-то поправят (вероятно, добавив новых дефектов, так как в сторону упрощения спецификация пока что идёт с большим трудом).

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

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

В Wired.com статья, рассказывающая о том, как Крис Робертс (Chris Roberts) попытался вмешаться в управление авиалайнером, находившимся в воздухе, с борта этого лайнера, и теперь агенты ФБР изъяли у Робертса компьютерное оборудование, которое собираются “обыскать”.

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

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

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