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

Популярная тема: если оснастить номерные знаки автомобилей радиометками (RFID), а дороги – считывателями (прототип системы, так сказать, есть в распоряжении профильного НИИ), то можно автоматизировать учёт нарушений правил дорожного движения и выписку штрафов. В ответ пользователи автодорожной сети пишут, что, мол, поставят металлические экраны – метки перестанут действовать.

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

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

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

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

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

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

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

Написал для издания TheRunet колонку про тотальное шифрование в вебе – в меру сил продвигаем использование TLS. Небольшая цитата:

Кроме правильного применения шапочки из фольги, важно не прийти к выводу, что HTTPS не делает вашу приватность «более приватной». Делает, ещё как: никакие теории заговора и «разоблачения Сноудена» не могут отменить того факта, что при использовании защищённого протокола в вашу сессию чтения новостного сайта не вмешается взломщик-одиночка, перехвативший управление устаревшей WiFi-точкой интернет-кафе, где вы расположились в компании с печеньками и чашечкой горячего напитка. Но не нужно чрезмерно доверять HTTPS. Если вы вдруг решили, что у вас есть какие-то действительно секретные сведения (а это является маловероятным: вспомните, что веб пока что не зашифрован полностью, поэтому откуда бы этим секретным сведениям взяться?) — защищать их нужно другими способами.

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

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

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

Чуть более года назад, 17 июня 2014 года, я писал буквально следующее:

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

Ждать, действительно, пришлось недолго: именно такую атаку, с лазерным излучателем, обещают представить на Black Hat Europe 2015. Действительно, технологии движутся, а о защите думают не так много. Впрочем, защита автомобилей от подобных активных помех – это вопрос едва ли не сложнее, чем аналогичная задача в случае, например, боевых истребителей.

Когда в 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 июля эта криптовалюта избежала катастрофы, но это, всё ж, преувеличение.