РегистрацияПрактическая реализация тайминг-атаки на контейнер 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)- т.е. ключ элементарного криптопреобразования зависит не только от ключа контейнера но и от номера сектора. Таким образом, путём тайминг-атаки можно вычислить исключительно этот элементарный ключ, который, без знания номера сектора (блока) ничем не поможет для вычисления собственно ключа контейнера.
Если же процесс-шпион будет обладать административными привилегиями, то он сможет использовать более совершенный способ извлечения кэшированного ключа смонтированного в настоящий момент криптоконтейнера путём атаки на реализацию. Хотя бы с помощью создания "присоединённой" отладочной сессии и т.п.
комментариев: 9796 документов: 488 редакций: 5664
Уважаемый обезкукленный 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
А какой криптоалгоритм из вышеуказанных следует выбрать для криптоконтейнера, имея в виду стойкость к тайминг-атаке? Неужели только ГОСТ?
комментариев: 9796 документов: 488 редакций: 5664
Во первых чем устойчивее шифр к тайминг атаке, тем обычно он менее устойчив к криптоанализу. Это трудно сочетать. Поэтому много споров возникает при разработке шифров – важны тайминг атаки или нет?
Все равно любой шифр к ним более или менее неустойчив и проблему надо решать на аппаратном уровне или на уровне ОС.
Все перечисленные Вами шифры содержат S-блоки, подверженные тайминг-атакам.
Режим CBC обычно используется совместно с вычислением уникального IV, а не ключа от номера блока.
Ключ шифрования обычно используется один и его легко можно вычислить.
Это плохое решение за неимением лучшего. Лучшее – ESSIV или multi-key ciphering mode
Надежных систем шифрования разделов и контейнеров НЕ СУЩЕСТВУЕТ! Их только пытаются создать: Есть только экспериментальные разработки под Linux:
http://mareichelt.de/pub/texts.cryptoloop.php
В модулях к Линукс ядру loop-aes как раз и созданы режимы многоключевого шифрования, чего мне кажется нет ни в Бэсткрипте, ни в других коммерческих продуктах.
Чтобы система шифрования диска была надежной нужно создать шифр, размер блока которого = размеру сектора диска = 4096 бит. Экспериментальные варианты таких шифров были созданы, но они все оказались нестойкими.
И создать такие шифры будет скорее всего очень трудно.
Компромиссное решение: использовать имеющиеся шифры и создать для них режим шифрования, которые бы "превращал" такие шифры в 4096-битные (по свойствам диффузии и перемешивания).
Хорошо бы доказать для таких режимов свойство "provable security", т.е., чтобы они были такие же стойкие как и исходный шифр с обычным размером блока.
Вернемся к "нашим баранам":
Тайминг атаки только больше усугубляют ситуацию. Cachetiming на уровне процессора раньше считались маловероятными, а по данным приведенной работы практически любой процесс в системе получить доступ к измерению времени исполнения других процессов.
Методика есть, запись на диск – лишь один из самых простейших вариантов атаки, возможно создать и что-то менее предсказуемое. Возможно, кто-то даже напишет массово доступные программы, похищающие ключи таким способом.
комментариев: 9796 документов: 488 редакций: 5664
GBDE – GEOM Based Disk Encryption
Poul-Henning Kamp
The FreeBSD Project
Просто в одной теме мы тут смешали и тайминг атаки и криптографическую ненадежность систем шифрования данных уровня bestcrypt. Можете сами делать выводы – можно ли доверять коммерческим системам шифрования, которые при всех их открытых исходниках уже давно никто не анализирует и серьезных научных работ по ним не проводит?
Во-первых: почему важен именно такой размер ключа и привязка именно к размеру сектора? Мы ведь ведём речь о симметричных криптоалгоритмах. Почему так много? Возможно, Вы имеете в виду просто длину ключа и размер блока элементарного криптопреобразования? По-моему, нет никакой нужды строго связывать размер блока и размер сектора.
Во-вторых размер сектора всегда был и есть на подавляющем большинстве систем 512 бит. И это строго зашито в железе. Вы не путаете его с размером кластера? Вот он – может довольно широко варьироваться. Почему важно строгое соответствие именно размера сектора а не кластера? Впрочем, в любом случае, на криптотоме всё это эмулируется и принципиальных затруднений быть не должно.
Возможно, Вы как-то связываете требуемый размер сектора с размерами кэша процессора? Но ведь эти размеры сейчас постоянно растут (2Мб например) и сильно превышают указанную Вами длину ключа...
комментариев: 9796 документов: 488 редакций: 5664
Размер ключа можно оставить 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-бит размером блока этого не обеспечивает.
Я сначала смеялся над коллегой, который бросился его выкачивать и устанавливать. А теперь и сам подумываю сделать так же.
Насколько это увеличит мою защищённость (т.е. например насколько возрастёт примерное количество элементарных тестовых раундов)? Линейно? Или?
комментариев: 63 документов: 5 редакций: 0
unknown! По-моему Вы и "Helsinki University of technology" – совершенно неправомерно смешиваете понятия физического сектора и кластера операционной системы. Поэтому и вышли непонятки у FW (который конечно же имел в виду 512-байтный размер физического сектора)
комментариев: 9796 документов: 488 редакций: 5664
В "Практической Криптографии" Шнайера и Фергюссона предлагается использовать 256-битный шифр для 128-битного уровня защищенности и 512-битный (а таких нету) для 256-битного (защита от коллизионных атак).
А у blowfish размер ключа большой, но размер блока всего 64-бита, что очень плохо для криптоконтейнеров.
Blowfish хорошо подходит для шифрования отдельных сообщений из-за сложного ключевого расписания.
комментариев: 9796 документов: 488 редакций: 5664
Да потому что во всех работах их абстрактно называют секторами.
комментариев: 9796 документов: 488 редакций: 5664
Используйте опцию тора TrackHostExits host,.domain,...
http://www.pgpru.com/forum/viewtopic.php?t=1096
комментариев: 63 документов: 5 редакций: 0
Думаю, речь идёт всё-таки о кластере. Но непонятно почему нужен имено "лавинный эффект" на весь сектор. Кажется логичным когда размер ключа по крайней мере равен или превышает размер блока. Иначе падает криптостойкость.
Ну вообще-то, насколько я знаю, размер блока AES в ВС составляет 256 бит. Как и размер ключа.
Почему вообще встал вопрос о привязке размеров блока шифра и "сектора/кластера"? Это мне кажется вторичным. Как мне представляется для противодействия тайминг-атаке следует одновремено увеличивать длину блока и ключа. При условии однонаправленой генерации индивидуального ключа для каждого блока например "из ключа контейнера и номера блока путём применения однонаправленной хэш-функции"
комментариев: 63 документов: 5 редакций: 0
Спасибо, знаю я её. Я просто обычный прокси предпочитаю использовать после сети Тор... И вручную их переключать – мне так удобнее... Сорри за оффтоп.