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

В рамках поддержки перспективного направления, я добавил на dxdt.ru поддержку криптосистемы ECDSA – это электронная подпись, использующая эллиптические кривые (в отличие от RSA). Для того, чтобы браузер мог использовать ECDSA, кроме поддержки браузером требуется специальный SSL-сертификат, выпущенный с подписью ECDSA. То есть, “традиционный” сертификат – не годится, так как он использует подпись RSA и, соответственно, в его составе опубликован ключ RSA, что, понятно, не позволяет применить ECDSA. (Кстати, не стоит путать ECDSA и DSA – сертификаты, использующие последнюю, в сети не встречаются, кроме редчайщих тестовых, а сама эта криптосистема признана невостребованной и вытесняется из браузеров.)

Итак, требуется сертификат, поддерживающий ECDSA – оказывается, пока что мало кто такие предлагает, хотя сертификаты удостоверяющих центров с ECC (криптографией на эллиптических кривых) есть. Я воспользовался Namecheap.com, где обнаружились относительно недорогие сертификаты Comodo PositiveSSL, для которых поддерживается ECC. Чтобы получить сертификат с ECDSA – нужно подготовить соответствующие ключи и соответствующий CSR (запрос на выпуск сертификата). Типовые CSR для RSA – не годятся: отправка такого CSR приведёт к тому, что вам выпустят RSA-сертификат. Сделать правильно можно силами OpenSSL:

$ openssl ecparam -name prime256v1 -genkey -out ec-prime256v1-private.pem

– генерирует ключ (секретный). Для ключа нужно выбрать кривую (криптосистемы используют различные кривые, из типовых наборов). Я выбрал кривую под названием prime256v1. Конечно, правильный выбор кривой – весьма важный шаг, известно, что “не все кривые одинаково полезны”. Но нужно учитывать и другие факторы: доступность кривой в сборке серверного ПО, фактические требования по защите информации. А также приходится учитывать невероятную путаницу, которая сложилась вокруг эллиптических кривых, используемых в практической криптографии. Например, prime256v1, как её называет OpenSSL, также известна как NIST P-256, кривая, рекомендованная для использования в информационных системах штатовских государственных структур – с некоторых пор, не лучший выбор. В общем, про кривые я как-нибудь напишу отдельно. Пока что на dxdt.ru используется prime256v1. Это “256-битная” кривая, что соответствет текущим представлениям об обеспечении достаточной секретности. (Естественно, ключ лучше защитить паролем.)

$ openssl req -new -key ec-prime256v1-private.pem -sha256 -out req.pem

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

Полученный сертификат я сейчас установил на сервер параллельно с RSA-сертификатом, который был раньше. То есть, браузеры (или боты), которые не поддерживают ECDSA – смогут установить соединение с RSA. Сервер может отличить таких клиентов на основе списка шифронаборов, который они передают в начальной стадии соединения. Думаю, что какое-то время RSA-сертификат будет присутствовать (у меня в запасе есть бесплатный от WoSign).

Надо заметить, что dxdt.ru таким образом оказывается в числе редких сайтов, поддерживающих современные ECDSA-сертификаты. В Рунете, впрочем, таких сайтов около 7,5 тыс. (уточнение 01/08/15: это уникальных сертификатов для Рунета около 7,5 тыс.), но это сайты, использующие сервис CloudFlare, который активно продвигает ECC и автоматически подключает своим клиентам TLS (даже если их сайты не умеют поддерживать HTTPS). Отдельных веб-узлов, не CloudFlare, отдающих валидные ECDSA-сертификаты – в Рунете пока практически нет.

Криптография на эллиптических кривых постепенно и тихонько вытесняет криптосистему RSA. Вот один из примеров, показывающий, когда “эллиптическая криптография” удобнее. Требуется сконструировать компактное устройство, смарт-карту, или, скажем, некий электронный “токен”, для использования в составе системы многофакторной авторизации. Устройство должно передавать в текстовом виде ответ на запрос, подписанный электронной подписью. Почему в текстовом? Потому что ответ передаётся по каналу, принимающему только текст (например, это веб-форма). Почему требуется подписывать? Для того, чтобы сервер мог проверить подлинность переданных данных. Передавать подпись в текстовом виде – несложно: используем кодирование Base64. Сравним две криптосистемы. Я взял проверочный текстовый файл и вычислил две подписи, используя OpenSSL (openssl dgst), – RSA и ECDSA.

Вот содержимое файла:

“Это тестовый файл, который содержит текст, используемый в качестве наполнения для тестового файла, в который этот текст входит.”

Подписи вычислялись не от самого файла, понятно, а от значения SHA-384, но, тем не менее – привожу для сравнения.

Вот закодированная в Base64 подпись RSA, ключ 2048 бит (это нижний предел высокой надёжности, по нынешним рекомендациям):

KO+1dEhOcqAsRM1TlaYoMDMoyxGPOIyVA88I6O4wk3RScLMlZs/sZ1fpoxVtHsRj
mSxG/oZfUmHP0L343eGwJBIa/jxXQj+swdTB7HccFetL4jfcKF0RlQjxZ4+zYRBK
9RJgU+YOlfNdV1g5bufNxb1K1ijWmM3i+di0giJji/b9lqrgg6E8XQJds+VVTUmt
bsk0slEtSG0DfWDLOentY/sEs3fzOdDMtvrxkzMFJr9X3UTGmK+Kr+9lCdooZn40
PSyRubv3PFJ48XyefGxmwIGbP904Yv2mq3MebzTBM5RZzkY9iHHN7cULAGzBRe3a
4DzFofoXWZeyZrg7xeKsTQ==

А вот результат ECDSA (с кривой secp384r1, стойкость операций на которой значительно превышает RSA с 2048-битным ключом):

MGUCMHBU6IxujyMSi4a7TroEr1iFAVspSawVqnhQzZG3YBpzVYAOtCvUGy2/3qvA
4SCp1AIxAJqdDMkmMyJBd5ptrK9ap+35NDoQTM2gT6N2aDFiWAERjxc/vbd2eL8q
TwRZwRRfYA==

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

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

Журналист Wired замечательно описывает, как два “автомобильных хакера”, находясь в собственном доме, удалённо сканируют сеть оператора мобильной связи и выуживают VIN-ы, IP-адреса и GPS-координаты уязвимых автомобилей, которые в этот момент едут где-то по дорогам, на расстоянии в сотни километров.

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

На “Хабрахабре” пресс-служба “Яндекса” признаёт, что их бот обходил URL-ы, которые в “Яндекс” сдаёт их же браузер:

Яндекс.Браузер собирает обезличенную статистическую информацию для улучшения качества Браузера, в которую включаются в том числе и адреса посещённых страниц. Это происходит только в том случае, если человек разрешил делать это в настройках программы (проставил галочку «Отправлять в Яндекс статистику использования»). Из-за технической ошибки информация о некоторых таких страницах из Браузера попала в список, индексируемый роботом Яндекса.

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

Пишут, что в Турции некие “хакеры” перехватили управление германскими ракетными комплексами Patriot. (“Хакеры” – в кавычках, потому что в данном случае нужно было бы назвать их “специалистами РЭБ”.) В качестве возможного транспорта для проведения атаки называют систему связи между ракетами (или пусковыми установками) и командным пунктом:

“German public sector magazine Behoerden Spiegel says one attack vector may be the sensor shooter interoperability which provides real-time information between command and weapons systems.”

Процитирую свою заметку, опубликованную более шести лет назад – там описан именно этот сценарий перехвата управления:

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

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

И ещё несколько ссылок на заметки по теме:

Сигнатуры, ПВО и утечки информации по побочным каналам;
Активация аппаратных “закладок” в специальных ЭВМ;
“Вскрытие” управления комплексом ПВО;
Атаки на специальные сети извне.

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

Похоже, что следом за компанией Land Rover, которая уже показала управляемый при помощи смартфона автомобиль Range Rover, подтягиваются и другие. Вот что пишут про новый E-класс:

Вместо привычного ключа-брелока отныне можно будет использовать смартфон с технологией NFC (Near Field Communication) […] Для того чтобы запереть или открыть машину, достаточно поднести смартфон к дверной ручке, а для запуска двигателя нужно положить мобильник на площадку для беспроводной зарядки батареи. С помощью смартфона можно будет и припарковать автомобиль.

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

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

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

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

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

Если смартфон (и, конечно, ключ от автомобиля) украли, то укравшие получают великолепную возможность переставить автомобиль, например, в трейлер, не проникая внутрь салона. Это просто замечательно для угонщика: всегда можно спокойно отойти в сторонку, если что-то пошло не так. Очевидно, что управлять автомобилем можно с большой дистанции. Да, для авторизации может использоваться ключ, но его достаточно просто приклеить скотчем на дверь. Вполне возможно, что приложение защищено паролем. Вопрос: насколько часто пароль будет реально использоваться, да ещё и будет отличаться от регистрационного номера автомобиля?

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

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

В доменной зоне .RU среди самых популярных названий УЦ, выдавшего серверный SSL-сертификат, неожиданно лидирует COMODO ECC Domain Validation Secure Server CA 2. Лидерство – по числу уникальных серверных сертификатов, которых, под доменами .RU, обнаруживается более 7 тыс.

Этим именем (COMODO ECC…) обозначается промежуточный SSL-сертификат, ключи от которого используются для подписывания клиентских, серверных сертификатов. Главная особенность сертификата в том, что он использует механизм электронной подписи ECDSA – на эллиптических кривых (то есть, используется не самая распространённая криптосистема RSA, а другая, как считается, более прогрессивная в плане длины ключей и используемых примитивов). Сертификат с криптографией на эллиптических кривых позволяет использовать эту криптографию и на сервере. Если у вас сертификат с подписью RSA, то сервер также должен использовать только RSA для генерации подписи, иначе браузеры не смогут корректно установить соединение.

Занятно, что виновником прогресса эллиптической криптографии в Рунете оказался сервис CloudFlare – именно он поддерживает большинство из тех сайтов, серверы которых отдают “эллиптические” сертификаты. Соответствующий промежуточный сертификат УЦ в CloudFlare используют для автоматической генерации на лету нужных валидных (признаваемых браузерами) сертификатов для клиентов. Так как CloudFlare на одних и тех же узлах обслуживает большое количество разных сайтов, необходимо использовать технологию SNI, чтобы определить сайт, к которому происходит обращение. А чтобы браузер не выдавал предупреждение – в составе сертификатов присутствуют все имена, которые поддерживает данный сервер: они перечислены в поле расширений SAN (Subject Alternative Name).

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

В работе исследователей, которые обнаружили уязвимость TLS Logjam, обсуждается возможность вычисления системами АНБ дискретного логарифма в некоторых группах, используемых в различных реализациях алгоритма Диффи-Хеллмана. (Задача дискретного логарифмирования, для правильно выбранных параметров, является вычислительно трудной, на этой трудности и основана практическая полезность протокола Диффи-Хеллмана.) Например, в решениях VPN, использующих IPsec (а это распространённая практика), для генерации общего ключа служат группы, заданные в рекомендациях (RFC). То есть, параметры известны заранее, это позволяет сильно ускорить процесс вычисления логарифма, выполнив предварительные вычисления.

АНБ, в теории, могло построить особый компьютерный кластер. В его основе – специализированные вычислители (ASIC), которые оптимизированы для выполнения конкретной задачи (вычисление арифметической структуры заданной группы). Если использовать современные технологии микроэлектронного производства, то узкоспециализированных вычислительных ядер в небольшом элементе кластера (в размере сервера типа blade, скажем) можно разместить тысячи (вспомните про современные видеокарты: там тысячи ядер, составляющих графический процессор, размещаются на одной небольшой плате). Предварительные вычисления для дискретного логарифмирования хорошо распараллеливаются. Миллионы ядер, допустим, позволяют вычислять структуру группы для 1024-битного модуля за год. После того, как предварительные вычисления сделаны, можно очень быстро (за минуты) раскрывать секретные ключи, полученные по протоколу Диффи-Хеллмана, из записанного трафика. А “предвычислитель” может заняться другой группой, потратив на неё ещё год, – это не так страшно, потому что одни и те же параметры в Сети действуют десятилетиями.

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