id: Гость   вход   регистрация
текущее время 02:15 29/03/2024
Автор темы: Гость, тема открыта 03/09/2005 11:01 Печать
https://www.pgpru.com/Форум/Криптография/ПрактическаяРеализацияТайминг-атакиНаКонтейнерBestCrypt
создать
просмотр
ссылки

Практическая реализация тайминг-атаки на контейнер BestCrypt


О практической реализации тайминг-атаки на криптоконтейнер BestCrypt'а c криптоалгоритмом AES.


unknown в http://www.pgpru.com/forum/viewtopic.php?t=1179

По данным исследователей:
Dag Arne Osvik and Adi Shamir and Eran Tromer
и их работы
"Cache attacks and Countermeasures: the Case of AES"


http://eprint.iacr.org/2005/271


Новые достижения в тайминг-атаках на примере шифрования AES ставят под угрозу безопасность многих систем,
делая бесполезным разделение контроля доступа к ключу.
В тестовых примерах на openSSL и Linux dm-crypt/cryptoloop ключ раскрывался за несколько сотен или тысяч попыток
в считанные секунды. Любой пользователь или процесс системы, какими бы ограниченными правами он не обладал,
может проделать эту операцию, например, если у него есть право на запись хотя бы одного файла в шифрованном разделе (контейнере).


Атаки основаны на измерении скорости работы памяти кэша процессора при проведении пробных шифрований. они также могут быть использованы удаленно. Например, посылая пакеты через VPN,
пользователь может вычислить ключ VPN, который используется и другими пользователями, а затем расшифровать данные из их потоков.


...


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


Для однопользовательских систем, подключенных к Интернету эту работу могут выполнить ActiveX компоненты, JAVA и JavaScript,
которые казалось бы должны быть изолированы от прямого доступа к ключам шифрования.


Небезопасен в этом плане запуск программ в изолированном окружении – виртуальных машинах, "песочницах", "chroot-jail environment".


Также от таких атак могут пострадать системы ограничения использования авторских прав – DRM.


Помимо шифрования AES могут быть уязвимы DES-подобные шифры, RSA, ECC и др.
В меньшей мере – криптопримитивы без S-блоков или времязависимых операций (Serpent, SHA).


Частичное решение проблемы тайминг-атак по мнению исследователей, может быть достигнуто, к примеру, в Linux-системах.
Это достигается за счет того, что криптографические примитивы включены в ядро ОС и к ним можно ограничить доступ "недоверенных" процессов. Альтернативный вариант – поддержка операционной системой специальных режимов для "чувствительных" участков кода.
...



Как мне представляется, злонамеренному приложению, для успешной реализации атаки потребуются в системе административные полномочия – для того, чтобы знать номер сектора, в который осуществляется запись. Ведь, насколько я себе представляю, при прозрачном зашифровании сектора криптоконтейнера как правило используется режим CBC (Cipher Block Chaining)- т.е. ключ элементарного криптопреобразования зависит не только от ключа контейнера но и от номера сектора. Таким образом, путём тайминг-атаки можно вычислить исключительно этот элементарный ключ, который, без знания номера сектора (блока) ничем не поможет для вычисления собственно ключа контейнера.


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


 
На страницу: 1, 2 След.
Комментарии
— Ghola (05/09/2005 14:06)   профиль/связь   <#>
комментариев: 63   документов: 5   редакций: 0
unknown:
Cachetiming на уровне процессора раньше считались маловероятными, а по данным приведенной работы практически любой процесс в системе получить доступ к измерению времени исполнения других процессов.
Методика есть, запись на диск – лишь один из самых простейших вариантов атаки, возможно создать и что-то менее предсказуемое. Возможно, кто-то даже напишет массово доступные программы, похищающие ключи таким способом.

А не кинете ссылку на методику? Любопытно как на её применимость влияет конкретная аппаратура. Например размер кэша процессора или наличие/отсутствие гипертреадинга/многоядерности...

Не окажется ли, например, что следует пересесть на Сеlеrоn'ы...

Имеет ли значение, что заранее неизвестен конкретный алгоритм (из подмножества реализованных в криптосистеме), который использован в криптоконтейнере...
— unknown (05/09/2005 14:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ну вообще-то, насколько я знаю, размер блока AES в ВС составляет 256 бит. Как и размер ключа.

AES != RIJNDAEL.

RIJNDAEL с размером блока 256-бит не стандартизован как AES.
Требование размера сектора (ну рассматривают их абстрактно, не вникают там в кластеры) НЕ СВЯЗАНО с тайминг атаками. Это самостоятельное условие криптостойкости против обычных атак.

А увеличение размера блока/ключа не является серьезным методом защиты от тайминг-атаки.
— unknown (05/09/2005 14:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А не кинете ссылку на методику?

В новости ссылка.
— unknown (05/09/2005 14:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Имеет ли значение, что заранее неизвестен конкретный алгоритм (из подмножества реализованных в криптосистеме), который использован в криптоконтейнере...

Это сложные методы, основанные на изоморфности RIJNDAEL (когда используя разные полиномы можно получить множество разных алгебраических вариантов алгоритма, таких же стойких как и сам RIJNDAEL). Были работы Шамира на эту тему, чего-то мне их никак не найти :-(

Но нельзя думать, что случайный выбор из нескольких десятков алгоритмов или случайное изменение параметров одного алгоритма чем-то затруднит атаку.
Защита от side-channel атак, основанная на использовании множества изоморфных шифров имеет достаточно сложную теорию и трудна в использовании. Мне неизвестно даже опытных образцов таких систем.
— unknown (05/09/2005 15:09)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А вот и все нашлось:

In How Many Ways Can You Write Rijndael?

Elad Barkan and Eli Biham

Abstract. In this paper we ask the question what happens if we replace all the constants in Rijndael, including the replacement of the irreducible polynomial, the coefficients of the MixColumn operation, the affine transformation in the S box, etc. We show that such replacements can create new dual ciphers, which are equivalent to the original in all aspects. We present several such dual ciphers of Rijndael, such as the square of Rijndael, and dual ciphers with the irreducible polynomial replaced by primitive polynomials. We also describe another family of dual ciphers consisting of the logarithms of Rijndael. We then discuss self-dual ciphers, and extend our results to other ciphers.

http://mirror.cr.yp.to/eprint.iacr.org/2002/157


Мгновенное восстановление (на основе тайминг атак) ключа шифрования в мобильных телефонах:
http://eprint.iacr.org/2004/049

См. также работы российских ученых Ростовцева и Шемякиной по защите от side channel атак с использованием случайного изоморфизма
filehttp://www.ssl.stu.neva.ru/ssl/archieve/sidetech1.pdf
— unknown (05/09/2005 16:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Кажется логичным когда размер ключа по крайней мере равен или превышает размер блока. Иначе падает криптостойкость.

О ключах и блоках (вперемешку с алгоритмом Диффи-Хэллмана) мы вдоволь наговорились здесь:
http://www.pgpru.com/forum/viewtopic.php?p=6143#6143

При условии однонаправленой генерации индивидуального ключа для каждого блока например "из ключа контейнера и номера блока путём применения однонаправленной хэш-функции"

Именно эта примитивная схема и расценивается как дырка в cryptoloop-устройстве ядра Linux, что послужило его заменой на dm-crypt в мэйнстрим-версии и loop-aes модулями в альтернативных вариантах (например в Gentoo). Но не по причине cachetiming-атак. От тайминг атак это тем более не спасает. Что и было продемонстрировано в работе Шамира.

Стоп. Ключ вообще-то один! Генерируется всего лишь IV для каждого блока, разворачивание подключей из ключа – медленная процедура, а хранить весь массив ключей в памяти не принято. В loop-aes многоключевое шифрование реализовано иначе. Массив ключей генерируется заранее и хранится в gpg-файле, но их число небольшое, не связанное с числом блоков.

Режимы, в которых для каждого блока генерируется новый ключ являются медленными, экспериментальными, плохо изученными и пока малостойкими.
— Гость (06/09/2005 23:09)   <#>
Получается, что криптоконтейнеры с AES не миеют смысла?
— unknown (07/09/2005 08:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
celeron:
Получается, что криптоконтейнеры с AES не миеют смысла?

AES здесь сам по себе ни причем. С любым шифром в той или иной степени. AES просто теперь самый распространенный и все исследователи на нем тренируются в создании новых атак.
Надежных систем построения криптоконтейнеров не существует. Так же как и хэш-функций. Одно дело – мы шифруем отдельное сообщение, если использовать каждый раз случайный вектор инициализации, то и шифртекст будет разным. Другое дело – криптоконтейнер. В нем будут меняться только отдельные сектора. Ну не весь же контейнер целиком. Тоже самое и для шифрованных баз данных. Еще у Шнайера в "Прикладной криптографии" об этом упоминалось. А как правильно нужно шифровать сектора? Точно никто не знает.
Для криптоконтейнеров нужно разрабатывать или новые режимы шифрования или новые шифры.

И не путайте это с тайминг-атаками. Они вообще сами по себе. Для защиты от них нужны еще более сложные средства, я не хочу тут разводить еще кучу теории. Я дал ссылки на работы, кому интересно, тот может разобраться.
— Гость (07/09/2005 09:03)   <#>
2 unknown
А какой алгоритм, по вашему мнению, больше подходит (в плане стойкости) для создания криптоконтейнеров? Зачем они тогда вообще применяются, если ключ раскрывается за считанные секунды??
— unknown (07/09/2005 09:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А какой алгоритм, по вашему мнению, больше подходит (в плане стойкости) для создания криптоконтейнеров?

Если система не может быть защищена от тайминг атак, то никакой. Можно конечно выбрать Serpent, но у него свои нюансы.

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

Ну подумайте сами, все таки тайминг-атака – эта активная атака, она должна быть осуществлена против конкретной цели, за которой противник долго следит и собирает информацию, а если вы просто потеряете свой ноутбук, то о тайминг-атаках можете не беспокоиться. Ваши данные (почти ;-) ) надежно зашифрованы.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3