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

Когда в 2010 году технологию DNSSEC внедрили в корневой зоне DNS – не подумали об алгоритме ротации (замены) корневого ключа. В процессе генерирования безопасного файла зоны участвуют два ключа: KSK и ZSK – последний подписывает записи в зоне, а первый, KSK, это и есть корневой ключ, он удостоверяет ZSK. Соответственно, вся валидация делается от корневого KSK (в зонах, которые находятся уровнем ниже, тоже есть свои KSK, но глобальный, корневой, порождает всю цепочку). Всякий валидирующий DNS-резолвер, если он работает с глобальной DNSSEC от IANA, должен содержать копию открытого ключа корневого KSK, это необходимо для проверки подписей из безопасных зон. В общем, корневой KSK – самый важный элемент инфраструктуры DNSSEC, и технология была запущена без алгоритма регулярной замены этого ключа (хотя про интервал замены “раз в пять лет” речь шла). Бывает.

Сейчас истекли пять лет с момента публикации подписанной корневой зоны DNS. KSK пора бы обновить. Это ключ RSA, имеющий длину 2048 бит. Маловероятно, что кто-то успел его факторизовать за пять лет, но есть же и криптографические традиции. Поэтому ICANN ведёт разработку алгоритма ротации корневого KSK, сейчас предварительный документ с рекомендациями проходит стадию публичного обсуждения.

Рекомендовано сохранить используемую криптосистему (RSA) и разрядность ключа (2048 бит), а дата ротации пока никакими рекомендациями не обозначена. Учитывая, что сейчас идёт процесс по “передачи IANA-функции”, всякие решения по точным алгоритмам и датам – могут только затягиваться (в документе по ссылке про изменение политик IANA, конечно, упомянуто).

Вообще, DNSSEC не слишком широко поддерживается – подписанных зон чрезвычайно мало. Не велико и число операторов валидирующих резолверов. Среди них, наверное, самый влиятельный по объёму запросов – Google, который предоставляет сервис Public DNS, поддерживающий DNSSEC. В теории, впрочем, при неудачной замене корневого KSK все валидирующие резолверы через некоторое время сломаются, потому что любая безопасная зона подписана от корня DNS, а подписи в корне перестанут валидироваться. На практике, новый KSK, с проверкой, можно раздать по крупным операторам вручную, а мелкие – починятся после того, как обнаружат сбой. (Несмотря на то, что есть RFC 5011, надеяться на массовую успешную автоматическую замену ключа было бы очень наивно – это уже не в традициях системного администрирования.)

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

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

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

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

Сам текст:

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

В продолжение заметки про сеансовые ключи TLS, генерируемые по протоколу Диффи-Хеллмана (DH). Этот протокол, в классическом случае, работает на “обычной” конечной группе (современный вариант использует группу точек эллиптической кривой – см. ниже). Группа DH задаётся единственным числом – модулем. Это обязательно большое простое число. На практике веб-серверы так настроены, что используют ту или иную типовую группу (или типовой модуль, что эквивалентно). Модуль не является секретным. То есть, известна группа, используемая большинством веб-серверов, поддерживающих DH (для Рунета это более 60% веб-серверов). Эта группа является 1024-битной, что не так много.

Вся практическая полезность DH строится на сложности задачи дискретного логарифмирования (отыскания по известным A,G такого e, что A = G^e). Так вот, один из моментов, на который обратили внимание авторы атаки на TLS Logjam, состоит в том, что если у вас много ресурсов, то, в теории, для 1024-битной группы можно уже сейчас предвычислить её арифметические структуры, потратив пару лет работы суперкомпьютера и сохранив результаты в специальных таблицах. После этого вычислять дискретный логарифм можно достаточно быстро (за часы, а возможно, даже в режиме онлайн), особенно, если вы используете специальную многопроцессорную систему. Это означает, что можно расшифровать записанный ранее трафик TLS-сессий (а также других протоколов, использующих DH). Дело в том, что сеансовый ключ, если вы умеете отыскивать дискретный логарифм, элементарно вычисляется из ключа DH, который передаётся в открытом виде. Предвычислить нужную структуру можно только для известной группы, поэтому важно, чтобы TLS-серверы использовали типовые параметры. При этом, для тех, у кого ресурсов мало (кто не является специализированным агентством, например), группа остаётся вполне стойкой.

Лирическое отступление: как упоминалось выше, есть современная разновидность DH, работающая на группе точек эллиптической кривой – ECDH. Этот протокол также распространён в современных реализациях TLS. Из-за особенностей групповой операции на эллиптической кривой, отыскание дискретного логарифма в такой группе сложнее, поэтому, во-первых, можно использовать более короткие ключи, и, во-вторых, использовать общую кривую. На практике самый распространённый случай – кривая secp256r1, предлагающая 256 бит. Естественно, на ум сразу приходят теории о том, что АНБ известна пара-тройка секретных теорем, которые позволяют резко уменьшить вычислительную сложность дискретного логарифмирования на кривой secp256r1 (которая, кстати, в АНБ и сконструирована).

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

В начале июля с биткоинами приключилась интересная и показательная история, последствия которой до сих пор дают о себе знать. Вот что произошло. В начале года предложили модификацию протокола (BIP66), которая изменяет требования к формату записи значения электронной подписи, используемой при проведении транзакций. Новые блоки, поддерживающие изменённый формат, должны иметь версию 3. Так как это существенное изменение, оно вводится согласованно, а именно: если из предыдущих 1000 блоков 950 имеют версию 3, то новые блоки, имеющие старую версию 2, считаются невалидными (не соответствующими протоколу). Или, другими словами, в блокчейне (цепочке Blockchain) должен появиться отрезок, на 95% состоящий из блоков новой версии, после этого блоки, имеющие старую версию, не принимаются, соответственно, если большинство узлов-майнеров следуют протоколу, цепочка должна мягко перейти на новую версию.

Но на практике случился занятный сбой. Некоторые майнеры, достаточно мощные пулы, приступают к вычислению нового блока без проверки параметров предыдущего блока, к которому они планируют пристроить новый. Эти майнеры генерируют блоки версии 3, но сами не проверяют, что предыдущий блок также является блоком версии 3. Собственно, они вообще ничего не проверяют, так как в погоне за скоростью начинают вычислять свой блок, как только увидят значение хеша для нового блока, только что включённого в блокчейн. При этом значение хеша они получают через тот или иной API, предоставляемый специальными серверами крупных майнинг-пулов, а не используют штатную P2P-сеть Биткоин. Естественно, значение хеша в принципе не позволяет понять, что за версия у предыдущего блока. (Такой метод майнинга, – SPV-майнинг, – кроме прочего, подразумевает, что в блок скорее всего не будет включено пользовательских транзакций, кроме транзакции, зачисляющей новые биткоины на адрес майнера.)

После того, как цепочка блоков достигла требуемого интервала в 95% блоков новой версии, небольшой майнинг-пул опубликовал новый блок, который только что вычислил. Этот майнер использовал необновлённое программное обеспечение, поэтому он добавил в блокчейн блок версии 2 (этот блок можно увидеть на сайте blockchain.info). Всё бы ничего, но торопливые майнеры, без проверки, быстро пристроили к этому блоку ещё пять, создав ветвление блокчейна: так как породивший ветку блок второй версии не должен был быть включен в блокчейн (из-за нарушения протокола), другие майнеры продолжали строить блокчейн от предыдущего блока. Это ветвление приключилось 4 июля 2015 года. Позже, невалидные блоки были вытеснены основной веткой, которая обогнала сбойный участок по сложности (протокол биткоин предписывает добавлять новые блоки в ветку с максимальной суммарной сложностью). Однако транзакции, попавшие в сбойную ветку оказались отменены, а ресурсы, потраченные на вычисление блоков – потеряны.

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

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

Вот так человеческий фактор и неверное управление доверием, – когда новый протокол принимают, но не проверяют присланные блоки на соответствие, – едва не привели к весьма большим неприятностям для биткоинов. Можно, кстати, услышать, что 4-5 июля эта криптовалюта избежала катастрофы, но это, всё ж, преувеличение.

В рамках поддержки перспективного направления, я добавил на 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). Занятно, что если автовладельцу злоумышленники подменили смартфон и, используя легитимное приложение, укатили машину, то даже позвонить в полицию этот автовладелец сумеет не сразу – телефона-то нет. Ну и, конечно, новое поколение троянских программ: если сейчас они заточены под банковские приложения, то появятся ветки для копирования цифровых ключей от автомобиля. Впрочем, если проникновение подобных цифровых технологий продолжит наращиваться теми же темпами, угонять автомобили не будет смысла – исчезнет поле для сбыта. Что не отменяет проделок с перехватом управления.