12.09 // Продемонстрирован JPEG-файл, превращающийся в PNG при AES-шифровании и в PDF после 3DES-дешифровки
Энджи Альбертини (Аnge Albertini), специализирующийся на экспериментах с обратным инжинирингом, упорным трудом сумел подобрать JPEG-изображение, которое при шифровании с использованием алгоритма AES превращается в другое изображение в формате PNG, а при расшифровке использованием алгоритма 3DES становится пустым документом в формате PDF. Секрет подобного превращения заключается в подборе начальных векторов инициализации для AES и 3DES, при которых первый блок исходного файла трансформируется в корректный заголовок форматов PNG и PDF.
Следует отметить, что это не первый эксперимент такого рода, в прошлом Энджи сумел сформировать файл PNG, который отображал изначальное изображение даже после AES-шифрования.
Youtube (English)
Источник: http://www.opennet.ru/opennews/art.shtml?num=40569
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Перечислять конкретные шифры для этого не имеет смысла. Это работает для всех шифров, так и должно быть. Интересно разве, что автор продвинулся в практической реализации, подобрав даже кроссалгоритменное (между разными шифрами) отображение, но с теоретической точки зрения — это примерно также тривиально, как взломать XOR (на нём ведь и построено зацепление блоков в CBC-шифровании) с некоторыми ограничивающими условиями — пользуясь современными компьютерами можно точно подобрать ещё и коллизии блоков для 64-битных блоков шифров.
Используйте только аутентифицированное подписью шифрование, как в PGP, или аутентифицированное посредсвом MAC, или специальных режимов (OCB, Keccak Authenticated Duplex Mode), или non-malleable encryption, что частично реализовано в дисковом шифровании XTS.
Подозреваю, что реально это может быть уязвимостью только для шифрпанковских режимов, таких как OpenPGP MDC.
Как понимать картинки на стр. 30 и 31? Почему шифрование изображения сохраняет его структуру, лишь незначительно зашумляя её?
комментариев: 11558 документов: 1036 редакций: 4118
Потому что в режиме ECB каждый блок шифруется независимо от других — перемешивание происходит только в рамках одного блока, общая структура данных при этом сохраняется. Это же классическая демонстрация, почему использовать ECB недопустимо.
комментариев: 9796 документов: 488 редакций: 5664
…с картинками, известными задолго до этой работы. См. их в вики.
Возможно, что часть новости трактуется слишком вольно или нераскрыта:
Скорее всего в конец или середину PNG были добавлены данные, выглядящие как мусор, но специально подобранные. При известном ключе, векторе инциализации и открытом тексте подбираются такие значения того, что подаётся на вход режима шифрования, что после шифрования изображение становится мусором, а мусор — изображением. И сделано так, что мусор заметается под ковёр, а из под ковра вынимается подставной фрагмент изображения: мусор перемещается на место изображения, а изображение на место мусора. Обрамляющие заголовки графических форматов файла делают так, что повреждённые мусорные части изображения не видны, а видны только правильные.
Это всё не имеет никакого отношения к слайдам про ECB в том плане, что картинки из этих слайдов не относятся напрямую к работе автора — показывать тривиальный режим (а по сути, отсутствие какого-либо режима) ECB не являлось целью его работы. Он манипулировал с CBC.
Единственно, что можно извлечь из работы автора, что шифрование в условиях опасности подмены шифртекста противником всегда должно сопровождаться аутентификацией. Можно обоснованно предположить, что даже не знаю ключа, зная не весь открытый текст и даже столкнувшись с каким-нибудь продвинутым режимом, наподобие XTS, противник сможет подменить данные в шифртексте как ему вздумается. Например, если операционка зашифрована полнодисковым шифрованием, то противник может подменить пароль пользователя в /etc/shadow и зайти на обслуживаемый этой операционкой сервер, понаставить троянов и откатить бэкап обратно к исходному шифртексту, чтобы замести следы. Естественно, также можно подменить любой исполняемый файл, а уж добавить нолики к суммам на денежном счёте — ещё проще. А потом удивления в виде «мы же храним в облаке только зашифрованные бэкапы, откуда наши враги узнали пароль? Они умеют ломать все шифры?» никому не будут интересны.
комментариев: 9796 документов: 488 редакций: 5664
Практически нигде. Только как элемент какого-нибудь протокола, где нужно одноразово (один раз одним ключом) зашифровавывать данные размером меньше одного блока (≤64…128 бит), да ещё с массой некоторых ограничений. Что-то вроде «Алиса посылает Бобу шифрованное симметричным шифром случайное число, размером 128 бит и хэш этого числа, Боб отсылает Алисе хэш шифртекста, связанный с каким-то предыдущим параметром, после чего Алиса раскрывает Бобу использованный ключ» и т.д. Т.е. ECB — это отсутствие зацепления блоков шифртекста, по сути это отсутствие режима шифрования. Ещё это может использоваться в каком-нибудь модельном криптоанализе (находят какой-нибудь различитель, сводящий стойкость к ECB за n шагов).
А то, как автор работы делает трюки с CBC и форматами файлов, скорее показывает пример протекания абстракций: все привыкли, что крипто даёт некий неразличимый псевдорэндом, но не думают о том, как это устроено и чем достигается, поэтому не зная особенности устройства режимов шифрования, могут неправильно их применять и полагаться на и надёжность в тех случаях, где они этого не обеспечивают.
Могло бы. Поэтому сейчас на дисковое шифрование можно полностью полагаться только если шифртекст сохраняется в полностью изолированном оффлайновом носителе и противнику только в момент X единоразово попадает копия шифртекста. Отсюда возникает невозможность сохранения побитовых бэкапов шифроконтейнеров.