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

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

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



Комментарии (7) »

DNS Privacy – актуальная тема. Речь здесь о том, как снизить утечки информации об использовании интернет-сервисов, происходящие через DNS. Как именно и какая информация утекает? В типичной пользовательской конфигурации, DNS служит базой данных, хранящей соответствие символьных имён и IP-адресов, а поиск в этой базе данных осуществляет рекурсивный резолвер интернет-провайдера (несколько реже – корпоративный рекурсивный резолвер).

Есть два основных потока утечек. Первый – это сведения об узлах, для которых запрашивались имена; во многих случаях эти данные близки к списку посещаемых веб-сайтов, но содержат и другие разнообразные сведения. Второй поток – “помеченный” трафик, характерный для конкретного браузера и конкретных веб-страниц. Ко второму случаю, например, относятся известные способы деанонимизации пользователей при помощи создания уникальных имён ресурсов, ссылки на которые встраиваются в код веб-страницы. Браузер, пытаясь извлечь ресурс по ссылке, отправит уникальный идентификатор страницы на сервер имён, поддерживающий зону DNS, которая послужила базисом в системе деанонимизации. Обычно маркером служит уникальное имя, созданное для конкретного запроса, например: kf356askg.example.com (уникальный идентификатор здесь – kf356askg). Интересно, что если вы просматриваете пользовательский DNS-трафик, то идентифицирующие маркеры можно распознавать и без использования серверов имён: они будут передаваться в открытом виде.

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

При штатной работе, DNS резолвер всегда начинает опрос серверов с полным именем искомого ресурса в составе запроса. На минуточку предположим, что в нашем простом случае исчезло кеширование. Тогда, если пользователь, например, задумал обратиться на www.example.com, то об этом имени, сопоставленном с IP-адресом используемого резолвера, узнают и корневые серверы глобальной DNS, и корневые серверы .COM, и серверы имён зоны EXAMPLE.COM. Так устроен протокол. При этом, если исходить из необходимости получения А-записи для www.example.com, знать о полном имени запроса нужно только серверам зоны EXAMPLE.COM (строго говоря, серверам WWW.EXAMPLE.COM, но эти детали мы опустим). Борьба с данной утечкой называется QNAME Minimization – есть RFC 7816, со статусом Experimental. Основная идея состоит в том, чтобы резолверы направляли запросы, минимизируя утечки информации. В случае с www.example.com – можно спрашивать корневые серверы сразу об именах серверов имён (NS) зоны .COM, и так далее.

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

Защите DNS-трафика от прослушивания и, частично, подмены, посвящена технология DNS over TLS, описанная в свежем RFC 7858. Мало кто ожидает, что в ближайшее время при помощи TLS будут защищены все DNS-транзакции, но технология позволяет это сделать. Параллельное решение – DNSCrypt, про который я рассказывал не так давно. Вариант с TLS выглядит несколько более предпочтительным, так как вписан в существующую технологическую архитектуру Сети, где TLS является основной для защиты трафика.



Комментировать »

Я уже как-то писал на эту тему: сенсорам автомобилей-роботов можно ставить активные помехи. Собственно, до этой задачи потихоньку добрались публично – Wired рассказывает о том, как исследователи ставят помеху радару автомобиля Tesla, а также и ультразвуковым датчикам препятствий этого же автомобиля. (Не ясно, почему выбрали Tesla – возможно, из-за максимальной медийной узнаваемости.)

Эта тема имеет историю в несколько десятков лет. Правда, она касается не автомобилей, а военных радиолокационных комплексов самого различного назначения. Помехи ставили и ставят бортовым РЛС истребителей и радарам наземных комплексов ПВО. В тексте Wired, впрочем, ничего про военные системы не сказано, но это не отменяет истории разработок. Постановка помех – довольно хитрая область, где наряду с передовыми методами обработки сигналов и сложной микроэлектроникой применяется такая математическая дисциплина, как теория игр. В случае с военной техникой от искусственных помех специально пытаются отстраиваться (про естественные – и так понятно). Например, радары могут использовать сигналы сложной структуры (и во временной, и в частотной области), которые сложно обнаружить (LPI) и, соответственно, сложно поставить активную помеху, вводящую систему в заблуждение. Для автомобильной техники этот вариант, скорее всего, просто не рассматривается: максимум, система управления учитывает естественные помехи и пытается обнаружить ситуацию потери точности измерения, чтобы сигнализировать об “отключении автопилота” (именно так действует Tesla из статьи). Проблема в том, что активный помехопостановщик может создать картинку, неотличимую от настоящей, с точки зрения системы управления. И это большая проблема, потому что автомобиль с таким помехопостановщиком может находиться в потоке транспорта, хоть это и похоже на сюжет из киберпанковского кинофильма.

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

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



Комментировать »

Road crossingВ экспериментальной версии Google Chrome добавлена поддержка “постквантовых” алгоритмов в TLS. “Постквантовая криптография” – это собирательный термин, обозначающий криптосистемы и отдельные алгоритмы, для которых не известно быстрых методов взлома на квантовом компьютере, либо доказано, что таких методов нет (строгое требование доказанного отсутствия возможности “квантового взлома” не является обязательным).

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

Вообще, пока никто не продемонстрировал на практике для сколь-нибудь мощных квантовых компьютеров работу алгоритмов, составляющих угрозу для асимметричных криптосистем. Таких компьютеров просто нет (устройства D-Wave не считаются, так как они не подходят). Учитывая, что вся вычислительная мощь данных алгоритмов кроется в физических свойствах окружающей действительности, нельзя исключать, что задача создания подходящего квантового компьютера окажется несравнимо труднее, чем принято считать сейчас: до сих пор нельзя со полной уверенностью сказать, что компьютер с 1024 кубитами вообще возможен практически. С другой стороны, одно дело – полная уверенность, а совсем другое – быстрое развитие прикладной науки. Так что угроза появления квантового компьютера достаточной мощности считается реальной уже сейчас, по этому поводу есть публикации NIST.

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

В Chrome добавили постквантовый протокол с рабочим названием New Hope, позволяющий сторонам договориться о сеансовых ключах. Вообще, в основе этой схемы (являющейся вариантом Ring-LWE, где LWE – это алгоритм Learning With Errors, реализованный для решётки, а кольцо там появляется из-за используемой арифметики и коэффициентов; но технические подробности я оставляю для другой записки) лежит та же математическая идея, что и в протоколе Диффи-Хеллмана. Однако принципиально иной фундамент позволяет добиться требуемой постквантовой стойкости. Почему для эксперимента выбрана схема получения сеансовых ключей? Отложенные атаки важны только для защиты ключей шифрования, а не для защиты аутентификации. Действительно: какой смысл во взломанной спустя год схеме аутентификации? Подменить узел постфактум – не получится. А вот раскрытие ключей симметричного шифра позволяет прочитать трафик. И, кроме того, с постквантовой аутентификацией ситуация обстоит несколько хуже, чем с алгоритмами распределения ключей.

Пока не понятно какие именно постквантовые схемы войдут в состав TLS и когда это произойдёт. Для полноценной замены имеющихся инструментов потребуется схема аутентификации, вместо RSA и ECDSA в SSL-сертификатах. Тут квантовый компьютер превращает сложившуюся практику в “тыкву”: раскрыв секретный ключ сервера, можно активно перехватывать сессии в его направлении. Не исключено, что поменяется сама логика распределения ключей.

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



Комментировать »

ksks7 (Техничная записка из области популярной криптологии, которая, думаю, будет полезна и на dxdt.ru.)

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

Если третья сторона записывает TLS-трафик, то вместе с ним сохраняются и данные, послужившие источником сеансовых ключей (в случае использования DH). Фактически, можно говорить о том, что эти ключи тоже сохраняются вместе с записанным трафиком. В этом и состоит тонкость, относящаяся к области различий между реально уничтоженными (или отсутствующими) и зашифрованными данными. Для восстановления ключей DH из записи трафика нужно обладать дополнительной информацией (либо уметь решать вычислительные задачи, которые сейчас считаются трудными). К такой дополнительной информации относится, скажем, состояние генератора псевдослучайных чисел, который использовался на стороне сервера (или клиента) при выработке сеансовых параметров DH.

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

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

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

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

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

(Впрочем, для AES тоже можно предложить научно-фантастический компьютер, решающий соответствующую систему уравнений: но такому компьютеру потребуется известный открытый текст, а для случая DH и логарифмирования – он не нужен.)



Комментарии (6) »

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



Комментарии (1) »

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



Комментарии (1) »

Одно из современных направлений в развитии технологий связи – это сверхкомпактные, экономичные модули, обеспечивающие передачу данных на большие расстояния. Основная область применения: различные датчики, управляющие устройства и прочие “умные” компоненты. LoRa – как раз относится к таким технологиям связи: миниатюрный модуль, радиомодем, потребляющий минимальную энергию и делающий возможной передачу данных на расстояние в километры (вплоть до десятков километров). LoRa – похоже, лидер по дальности. Однако данная область не исчерпывается одним протоколом: здесь также действуют ZigBee, Bluetooth 4.0, Sigfox и др. Но эта заметка о том, как LoRa работает в реальности, на живом примере пары бюджетных модулей от NiceRF. (С картинками.)

Читать полностью



Комментарии (2) »

(Поделюсь на dxdt.ru такой репликой про “ключи и шифрование”.)

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



Комментарии (2) »
Навигация по запискам: Раньше »