Практическая реализация тайминг-атаки на контейнер 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)- т.е. ключ элементарного криптопреобразования зависит не только от ключа контейнера но и от номера сектора. Таким образом, путём тайминг-атаки можно вычислить исключительно этот элементарный ключ, который, без знания номера сектора (блока) ничем не поможет для вычисления собственно ключа контейнера.
Если же процесс-шпион будет обладать административными привилегиями, то он сможет использовать более совершенный способ извлечения кэшированного ключа смонтированного в настоящий момент криптоконтейнера путём атаки на реализацию. Хотя бы с помощью создания "присоединённой" отладочной сессии и т.п.
2 Ghola – без cookies!
Уважаемый обезкукленный Ghola!
У вас уже что 2^128 секторов на винчестере? Хотелось бы посмотреть! Энергии не много потребляет?
А если серьезно, число секторов легко можно перебрать. Вы немного путаете режим CBC и режим "key multiciphering".
Режим CBC для криптоконтейнеров постепенно устаревает, в Linux dm-crypt его заменили на ESSIV – encrypted salted sector initialisation vector (по памяти пишу, но точность не важна, главное смысл).
Режим "multiciphering" внедрен только в Linux loop-aes.
Как там обстоят дела в bestcrypt – не знаю. Рискну предположить, что хуже. Обсуждали мы это здесь: http://www.pgpru.com/forum/viewtopic.php?t=281&start=15
Если атака успешно продемонстрирована на устройствах шифрования ядра Linux и представлена на CRYPTO2005, то думаю, что и выбранный вами бэсткрипт она затрагивает. Причем не только с шифром AES.
А разве ключ элементарного криптопреобразования не вычисляется из ключа контейнера и номера блока путём применения однонаправленной хэш-функции? Или об этом только идёт речь?
Позволю себе цитату из справочной документации BC:
Encryption Algorithms: Blowfish, GOST, Rijndael and Twofish
Blowfish
The Blowfish is a fast encryption algorithm designed by Bruce Schneier. Bruce Schneier is well known as a president of Counterpane Systems, a security consulting firm, and author of Applied Cryptography: Protocols, Algorithms, and Source Code.
The Blowfish encryption algorithm was specially designed to encrypt data on 32-bit microprocessors. Blowfish is significantly faster than DES and GOST when implemented on 32-bit microprocessors, such as the Pentium or Power PC.
The original Blowfish paper was presented at the First Fast Software Encryption workshop in Cambridge, UK (proceedings published by Springer-Verlag, Lecture Notes in Computer Science #809, 1994) and the April 1994 issue of Dr. Dobbs Journal. In addition, "Blowfish--One Year Later" appeared in the September 1995 issue of Dr. Dobb's Journal.
BestCrypt software uses the Blowfish in Cipher Block Chaining Mode with 256-bit key length and 16 rounds.
Additional information about the Blowfish algorithm is available also on World-Wide-Web from: http://www.counterpane.com/blowfish.html
//[u:8674bec68f]GOST//[/u:8674bec68f]
The Government Standard of the USSR 28147-89, Cryptographic protection for Data Protection Systems, appears to have played a role in the former Soviet Union (not only in Russia) similar to that played by the US Data Encryption Standard (FIPS 46). When issued, GOST bore the minimal classification 'For Official Use,' but is now said to be widely available in software both in the former Soviet Union and elsewhere. The introduction to GOST28147-89 contains the intriguing remark that the cryptographic transformation algorithm "does not place any limitations on the secrecy level of the protected information."
The GOST 28147-89 standard includes output feedback and cipher feedback modes of operation, both limited to 64-bit blocks, and a mode for producing message authentication codes.
//[u:8674bec68f]Rijndael//[/u:8674bec68f]
This algorithm was invented by Joan Daemen and Vincent Rijmen. Recently, the National Institute of Standards and Technology (http://www.nist.gov/) selected the algorithm as an Advanced Encryption Standard (AES).
The cipher has a variable block length and key length. Authors of the algorithm currently specify how to use keys with a length of 128, 192, or 256 bits to encrypt blocks with a length of 128, 192 or 256 bits (all nine combinations of key length and block length are possible).
BestCrypt uses Rijndael with a 256-bit key in Cipher Block Chaining mode.
To get more information on the algorithm, visit the Rijndael Home Page: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/.
//[u:8674bec68f]Twofish//[/u:8674bec68f]
The Twofish encryption algorithm was designed by Bruce Schneier, John Kelsey, Chris Hall, Niels Ferguson, David Wagner and Doug Whiting.
Twofish is a symmetric block cipher; a single key is used for encryption and decryption. Twofish has a block size of 128 bits, and accepts a key of any length up to 256 bits.
The National Institute of Standards and Technology (NIST) investigated Twofish as one of the candidates for the replacement of the DES encryption algorithm. As the authors of the algorithm state, “we have spent over one thousand hours cryptanalyzing Twofish, and have found no attacks that go anywhere near breaking the full 16-round version of the cipher”.
BestCrypt uses a full 16-round version of Twofish and a maximum possible 256-bit encryption key length. To encrypt virtual drives, BestCrypt uses the Cipher Block Chaining Mode. To encrypt a block of data less than 128 bits, the Cipher-Feedback mode is used.
Additional information about the Twofish algorithm is available also on the World-Wide-Web from:
http://www.counterpane.com/twofish.html
Да, кстати, прочитал про CBC – действительно он никак не поможет:
А какой криптоалгоритм из вышеуказанных следует выбрать для криптоконтейнера, имея в виду стойкость к тайминг-атаке? Неужели только ГОСТ?
Вот накидали тут кучу цитатного текста, можно было пару основных предложений выбрать.
Во первых чем устойчивее шифр к тайминг атаке, тем обычно он менее устойчив к криптоанализу. Это трудно сочетать. Поэтому много споров возникает при разработке шифров – важны тайминг атаки или нет?
Все равно любой шифр к ним более или менее неустойчив и проблему надо решать на аппаратном уровне или на уровне ОС.
Все перечисленные Вами шифры содержат S-блоки, подверженные тайминг-атакам.
Режим CBC обычно используется совместно с вычислением уникального IV, а не ключа от номера блока.
Ключ шифрования обычно используется один и его легко можно вычислить.
Это плохое решение за неимением лучшего. Лучшее – ESSIV или multi-key ciphering mode
Надежных систем шифрования разделов и контейнеров НЕ СУЩЕСТВУЕТ! Их только пытаются создать: Есть только экспериментальные разработки под Linux:
http://mareichelt.de/pub/texts.cryptoloop.php
В модулях к Линукс ядру loop-aes как раз и созданы режимы многоключевого шифрования, чего мне кажется нет ни в Бэсткрипте, ни в других коммерческих продуктах.
Чтобы система шифрования диска была надежной нужно создать шифр, размер блока которого = размеру сектора диска = 4096 бит. Экспериментальные варианты таких шифров были созданы, но они все оказались нестойкими.
И создать такие шифры будет скорее всего очень трудно.
Компромиссное решение: использовать имеющиеся шифры и создать для них режим шифрования, которые бы "превращал" такие шифры в 4096-битные (по свойствам диффузии и перемешивания).
Хорошо бы доказать для таких режимов свойство "provable security", т.е., чтобы они были такие же стойкие как и исходный шифр с обычным размером блока.
Вернемся к "нашим баранам":
Тайминг атаки только больше усугубляют ситуацию. Cachetiming на уровне процессора раньше считались маловероятными, а по данным приведенной работы практически любой процесс в системе получить доступ к измерению времени исполнения других процессов.
Методика есть, запись на диск – лишь один из самых простейших вариантов атаки, возможно создать и что-то менее предсказуемое. Возможно, кто-то даже напишет массово доступные программы, похищающие ключи таким способом.
GBDE – GEOM Based Disk Encryption
Poul-Henning Kamp
The FreeBSD Project
http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
Просто в одной теме мы тут смешали и тайминг атаки и криптографическую ненадежность систем шифрования данных уровня bestcrypt. Можете сами делать выводы – можно ли доверять коммерческим системам шифрования, которые при всех их открытых исходниках уже давно никто не анализирует и серьезных научных работ по ним не проводит?
Прошу прощения, но вот это высказывание мне непонятно:
Во-первых: почему важен именно такой размер ключа и привязка именно к размеру сектора? Мы ведь ведём речь о симметричных криптоалгоритмах. Почему так много? Возможно, Вы имеете в виду просто длину ключа и размер блока элементарного криптопреобразования? По-моему, нет никакой нужды строго связывать размер блока и размер сектора.
Во-вторых размер сектора всегда был и есть на подавляющем большинстве систем 512 бит. И это строго зашито в железе. Вы не путаете его с размером кластера? Вот он – может довольно широко варьироваться. Почему важно строгое соответствие именно размера сектора а не кластера? Впрочем, в любом случае, на криптотоме всё это эмулируется и принципиальных затруднений быть не должно.
Возможно, Вы как-то связываете требуемый размер сектора с размерами кэша процессора? Но ведь эти размеры сейчас постоянно растут (2Мб например) и сильно превышают указанную Вами длину ключа...
Размер ключа можно оставить 256 бит, а вот размер блока шифра увеличить до 4096 бит.
512 байт * 8 = 4096 бит, я ничего не перепутал?
Есть различие между физическими, логическими и "виртуальными", представленными на уровне ОС-filesystem секторами.
Вот цитата, чтобы не запутаться:
!!(green)
"File system (upper layer) from our viewpoint accesses data as sectors. In our terminology a sector is a logical unit consisting of 512 bytes (4096 bits); larger physical sectors must be split into 512-byte pieces. We use this convention regardless of the actual sector size used by the file system (typically 1024, 2048 or 4096 bytes in the case of EXT2"
Encrypted Watermarks and Linux Laptop Security
Markku-Juhani O. Saarinen
Helsinki University of technology
!!
А зачем изобретают такие алгоритмы как Herring, Mercy, криптоконструкцию "BEAR and LION"?
См. например http://www.ciphergoth.org/crypto/mercy/
С размером БЛОКА 4096-бит! Не от безделья же, а для попытки решить проблему криптоконтейнеров.
Нет, просто Ghola стал обсуждать как считаются ключи в CBC и с cachetiming-атак мы резко перешли
к обсуждению режимов шифрования контейнеров.
По мнению Poul-Henning Kamp из The FreeBSD Project (ссылка на работу выше) злоумышленник (a.k.a. спецслужбы) может вскрыть
любой контейнер за 5-10 лет чисто криптоаналитическими методами. Без использования тайминг атак. При использовании стойких шифров.
А если есть копии одного и того же контейнера? Сделанные в разное время с разным содержанием и возможно некоторые другие хитрости,
то все будет выполнено быстрее.
Это необходимо для того, чтобы замена и перемешивание в секторе были полными. Изменили один бит в секторе – получили криптостойкое псевдослучайное изменение всех битов сектора (pseudorandom permutation). Нужен лавинный и диффузионный эффект на весь сектор.
Режим CBC со 128-бит размером блока этого не обеспечивает.
Ага, а я вот ещё о чём хотел спросить. На оффсайте BestCrypt'а (_www.jetico.com) можно загрузить драйвер, реализующий Blowish 448
Я сначала смеялся над коллегой, который бросился его выкачивать и устанавливать. А теперь и сам подумываю сделать так же.
Насколько это увеличит мою защищённость (т.е. например насколько возрастёт примерное количество элементарных тестовых раундов)? Линейно? Или?
"Гость" выше – это я. Похоже, пока писал, Tor переключил цепочку.
unknown! По-моему Вы и "Helsinki University of technology" – совершенно неправомерно смешиваете понятия физического сектора и кластера операционной системы. Поэтому и вышли непонятки у FW (который конечно же имел в виду 512-байтный размер физического сектора)
В "Практической Криптографии" Шнайера и Фергюссона предлагается использовать 256-битный шифр для 128-битного уровня защищенности и 512-битный (а таких нету) для 256-битного (защита от коллизионных атак).
А у blowfish размер ключа большой, но размер блока всего 64-бита, что очень плохо для криптоконтейнеров.
Blowfish хорошо подходит для шифрования отдельных сообщений из-за сложного ключевого расписания.
Да потому что во всех работах их абстрактно называют секторами.
Используйте опцию тора TrackHostExits host,.domain,...
http://www.pgpru.com/forum/viewtopic.php?t=1096
Думаю, речь идёт всё-таки о кластере. Но непонятно почему нужен имено "лавинный эффект" на весь сектор. Кажется логичным когда размер ключа по крайней мере равен или превышает размер блока. Иначе падает криптостойкость.
Ну вообще-то, насколько я знаю, размер блока AES в ВС составляет 256 бит. Как и размер ключа.
Почему вообще встал вопрос о привязке размеров блока шифра и "сектора/кластера"? Это мне кажется вторичным. Как мне представляется для противодействия тайминг-атаке следует одновремено увеличивать длину блока и ключа. При условии однонаправленой генерации индивидуального ключа для каждого блока например "из ключа контейнера и номера блока путём применения однонаправленной хэш-функции"
Спасибо, знаю я её. Я просто обычный прокси предпочитаю использовать после сети Тор... И вручную их переключать – мне так удобнее... Сорри за оффтоп.
А не кинете ссылку на методику? Любопытно как на её применимость влияет конкретная аппаратура. Например размер кэша процессора или наличие/отсутствие гипертреадинга/многоядерности...
Не окажется ли, например, что следует пересесть на Сеlеrоn'ы...
Имеет ли значение, что заранее неизвестен конкретный алгоритм (из подмножества реализованных в криптосистеме), который использован в криптоконтейнере...
AES != RIJNDAEL.
RIJNDAEL с размером блока 256-бит не стандартизован как AES.
Требование размера сектора (ну рассматривают их абстрактно, не вникают там в кластеры) НЕ СВЯЗАНО с тайминг атаками. Это самостоятельное условие криптостойкости против обычных атак.
А увеличение размера блока/ключа не является серьезным методом защиты от тайминг-атаки.
В новости ссылка.
Это сложные методы, основанные на изоморфности RIJNDAEL (когда используя разные полиномы можно получить множество разных алгебраических вариантов алгоритма, таких же стойких как и сам RIJNDAEL). Были работы Шамира на эту тему, чего-то мне их никак не найти :-(
Но нельзя думать, что случайный выбор из нескольких десятков алгоритмов или случайное изменение параметров одного алгоритма чем-то затруднит атаку.
Защита от side-channel атак, основанная на использовании множества изоморфных шифров имеет достаточно сложную теорию и трудна в использовании. Мне неизвестно даже опытных образцов таких систем.
А вот и все нашлось:
http://mirror.cr.yp.to/eprint.iacr.org/2002/157
Мгновенное восстановление (на основе тайминг атак) ключа шифрования в мобильных телефонах:
http://eprint.iacr.org/2004/049
См. также работы российских ученых Ростовцева и Шемякиной по защите от side channel атак с использованием случайного изоморфизма
http://www.ssl.stu.neva.ru/ssl/archieve/sidetech1.pdf
О ключах и блоках (вперемешку с алгоритмом Диффи-Хэллмана) мы вдоволь наговорились здесь:
http://www.pgpru.com/forum/viewtopic.php?p=6143#6143
Именно эта примитивная схема и расценивается как дырка в cryptoloop-устройстве ядра Linux, что послужило его заменой на dm-crypt в мэйнстрим-версии и loop-aes модулями в альтернативных вариантах (например в Gentoo). Но не по причине cachetiming-атак. От тайминг атак это тем более не спасает. Что и было продемонстрировано в работе Шамира.
Стоп. Ключ вообще-то один! Генерируется всего лишь IV для каждого блока, разворачивание подключей из ключа – медленная процедура, а хранить весь массив ключей в памяти не принято. В loop-aes многоключевое шифрование реализовано иначе. Массив ключей генерируется заранее и хранится в gpg-файле, но их число небольшое, не связанное с числом блоков.
Режимы, в которых для каждого блока генерируется новый ключ являются медленными, экспериментальными, плохо изученными и пока малостойкими.
Получается, что криптоконтейнеры с AES не миеют смысла?
AES здесь сам по себе ни причем. С любым шифром в той или иной степени. AES просто теперь самый распространенный и все исследователи на нем тренируются в создании новых атак.
Надежных систем построения криптоконтейнеров не существует. Так же как и хэш-функций. Одно дело – мы шифруем отдельное сообщение, если использовать каждый раз случайный вектор инициализации, то и шифртекст будет разным. Другое дело – криптоконтейнер. В нем будут меняться только отдельные сектора. Ну не весь же контейнер целиком. Тоже самое и для шифрованных баз данных. Еще у Шнайера в "Прикладной криптографии" об этом упоминалось. А как правильно нужно шифровать сектора? Точно никто не знает.
Для криптоконтейнеров нужно разрабатывать или новые режимы шифрования или новые шифры.
И не путайте это с тайминг-атаками. Они вообще сами по себе. Для защиты от них нужны еще более сложные средства, я не хочу тут разводить еще кучу теории. Я дал ссылки на работы, кому интересно, тот может разобраться.
2 unknown
А какой алгоритм, по вашему мнению, больше подходит (в плане стойкости) для создания криптоконтейнеров? Зачем они тогда вообще применяются, если ключ раскрывается за считанные секунды??
Если система не может быть защищена от тайминг атак, то никакой. Можно конечно выбрать Serpent, но у него свои нюансы.
Как говорил Шнайер – пусть операционная система и рабочий компьютер ненадежны – но это уже на совести их производителей. Производители криптопрограмм могут лишь сделать свои программы хорошими для "очистки совести", они не могут переделать все железо и операционку. Вот почему у военных всегда использовалось шифрование на своих микросхемах и железе, а в АНБ есть свой подземный комплекс по изготовлению криптопроцессоров (этакий завод Интел в миниатюре – это не слухи, сам видел в документальном фильме :-).
Ну подумайте сами, все таки тайминг-атака – эта активная атака, она должна быть осуществлена против конкретной цели, за которой противник долго следит и собирает информацию, а если вы просто потеряете свой ноутбук, то о тайминг-атаках можете не беспокоиться. Ваши данные (почти ;-) ) надежно зашифрованы.