Журнал Витуса

Ну вообще-то ХОРОШИЕ алгоритмы шифрования - как раз весьма ресурсоёмкие, и при этом получающийся поток критичных для анализа действий/данных наиболее шумоподобен в спектральном смысле. Иными словами, если отфильтровать "линейчатый спектр" шума от прочих операций, оставшаяся шумоподобная часть будет более интересной для выкапывания в ней криптоалгоитмов и их данных.

From:

schegloff.livejournal.com

Аудиоректальный криптоанализ.

From:

nomadmoon-proxy.livejournal.com

Кроме того ~~доктор едет едет сквозь снежную равнину~~ патчи для GnuPG уже вышли:
http://lists.gnupg.org/pipermail/gnupg-announce/2013q4/000337.html

From:

serge shikov (from livejournal.com)

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

Т.е., грубо говоря, один текст шифруется/дешифруется в недрах SSL/TLS столько-то наносекунд, а другой - несколько дольше, и из этой разницы во времени даже можно сделать вывод о свойствах открытого текста.

Из каждого алгоритма всегда наружу что-то торчит, за что можно подергать, какие-то виртуальные свойства.

Из каждого компьютера сегодня торчит еще больше физически измеряемых величин. Излучения в любом диапазоне. Вопрос только в возможности принять их и выделить из окружающего шума - но как раз в этой области уже давно был достигнут серьезный прогресс.

Ну так и что?

Что криптография, как техническое средство защиты, обычно ничего не стоит без средств огранизационных - это всегда было известно.

From:

В данном случае "благородные доны поражены в пятку" достаточной для получения неблагого результата чрезвычайно малой шириной полосы анализируемого сигнала. И тем, что никакого особенного датчика не нужно - "все гаджеты умеют это".

From:

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

From:

http://rnd.cnews.ru/math/news/top/index_science.shtml?2013/08/21/539821
Кстати.
Тоже ведь частично извлечение из функционального шума, в сущности.

Edited Date: 2013-12-19 06:00 am (UTC)

From:

Читаю бумажку, пока не убеждает. Убедил, что можно определять тип операции в цикле, совершенно не убедил, что приложения можно принудить к выполнению цикла с заданными данными достаточно длительное время, чтобы получить паттерн непрерывного исполнения инструкции.

(хотя ещё не дочитал)

From:

Вот и у меня ощущение, что оная бумажка - просто план прикрытия Моссада, какой-то успешной операции по тыренью ключей.

From:

Я её всё ещё не дочитал. До середины я вообще думал, что ахинея, но идея repeative cycle меня убедила. (Любой, кто слышал как скроллится экран на звуковухе с хреновой развязкой по питанию, поймёт).

А вот как они сумели принудить gnupg к выполнению repeative cycle, да ещё такой, чтобы оно повторяло операцию с ключом достаточно долго - не знаю. Но, ещё не дочитал.

From:

Один из красивых вариантов - ведём активную переписку емейлом с атакуемым персонажем, шифруя отсылаемые ему письма его публичным ключом.

From:

Я не понимаю, какого размера должны быть письма, чтобы оно достаточно долго пищало. Мелкие письма расшифровываются слишком быстро, а гигантские аттачи просто будут долго читаться/получаться (то есть crypto там будет мало, а вот IOwait много).

From:

Если честно, я прочитал всё внимательно.
И пока мне не доведётся увидеть такое в реальной работе, немного не верю.

Реальная работа - это свежесетапленная заранее не известная демонстраторам система без софта, со всеми патчами, браусер, вебмейл, GPG плагин. Свежесгененрированная пара ключей, по емейлу отослан собеседнику публичный.

From:

Письма должны быть - во-первых большие, во-вторых их должно быть очень много (там надо двадцать замеров атаки на каждый из бит). В третьих - никто не будет вести активную переписку с атакующими битовыми последовательностями :). В четвертых - а как атакующий узнает, в какой момент начали расшифровывать именно его письмо.
Ну в качестве fatality - а если расшифровывать будут сразу два письма? :)

From:

1) показано что генерируемый шум зависит от исполняемого кода. Но нам то нужен не код а данные.
Данные что 1+1 и 1+0 дают разный шум - отсутствуют, хотя это первое что стоит проверить.
Т.е. фактически все что слышно - изменения алгоритма, который от данных зависит косвенно. Но таки зависит.

2) частота дискретизации.
для гигагерцовых частот процессора представляется крайне сомнительным, чтобы изменение 1го бита фонило на частоте 35-38кГц сколь-нибудь существенное время. Из п. 1 прямо следует, что для получения результата необходимы многократные повторения на сгенерированных атакующим данных. Они там по 20 раз проводят атаку на каждый бит и берут среднее. Т.е. не невозможно, но абсолютно бессмысленно для любых практических применений.

3) Утверждается что параллельная загрузка скорее помогает атакующему понижая частоту шума.
Замеряли они вводя параллельный поток с ADD. Возникает банальный вопрос - если параллельно будет считаться два разных RSA с разными ключами - какой из ключей будет уязвим?

From:

Я бы даже уточнил, насчёт параллельной нагрузки. Если есть параллельный поток с ADD, отлично, всё хорошо. А если поток не с бесконечным ADD, а, например, с ютубовским роликом через флеш, в котором операции, хм, несколько более разнообразны, чем в зацикленном add?

From:

В любой современной системе и без ютубовского ролика крутится дофига всего.
И довольно много из этого всего использует шифрование. Браузер с потоком https, ssh/ssl, внутрисистемные шифрованные операции. Ну и сжатие - тоже будет давать своеобразные паттерны в звуке.

From:

Тоже интересная версия. Вполне последовательная и (простым путём) неопровержимая. :)

From: