Атаки на PGP-Disk и TrueCrypt на основе открытых данных
Описание теоретической ситуации:
(С технической точки зрения, это наверно, атака на блочные шифра на основе большого кол-ва открытых данных).
Dопустим вышел какой-нибудь модный иностранный фильм.
Пользователь допустим используя P2P сети, скачал себе его на компьютер и разместил в томе PGP-Disk или True Crypt.
Размер фильма достаточно велик, предположим более 3 Гб что по современным меркам довольно не мало. Копии фильма (открытой информации) существуют на тысячах других носителях.
Вдруг, господин В. В. дал указание:
В связи с экономической выгодой для РФ приступить ко всем методам чтобы ускорить вступление РФ в ВТО.
Первым и главным требованием вступления РФ в ВТО является борьба с пиратством.
Dошло это указание и до спец. служб РФ. Спецслужбы зашевелились, стали прослушивать (а может и стали прослушивают) P2P сети.
Засекли, что какой-нибудь пользователь скачивает себе пиратскую копию того самого модного фильма. Подумали, а не плохо бы его накрыть и опубликовать на весь мир, как спец. службы РФ бороться с пиратством, внося тем самым лепту в ускорение вступления в ВТО. …и продемонстрировав беспрекословное подчинение и выполнение вышестоящих. указов.
Вычислили IP-адрес пользователя, что качал себе тот самый фильм, посмотрели что за провайдер, зашли в гости к прову на чай и поинтересовались на какое лицо оформлен данный IP и пришли к пользователю в гости.
Силовики сделали своё дело, компьютер изъяли. Отдали специалистам для нахождения пиратской копии фильма для последующего доказательства в суде, о вине в пиратской деятельности.
Поскольку P2P сети основаны на обмене, могут пришить что, пользователь данный фильм распространял, нанеся ужасный урон издателю фильма.
Или альтернативный вариант. Издатель фильма узнаёт, что пиратские копии фильма с дикой скоростью распространяются через P2P сети. Скачивая фильм по P2P сетям, пользователь автоматически становится распространителем или соучастником. Издатель фильма финансирует группу злых дядек чтобы те поймали распространителей пиратских копий и привлекли их к ответственности. Акция устрашения чтобы другим не по делом было.
Вернёмся к следующему: специалистам спец. служб известно что на носителе находится пиратская копия. Требуется доказать что она там есть. Среди открытой информации на HDD она нигде не найдена. Обнаруживается PGP-Disk или TrueCrypt том большого размера. С большой вероятностью предполагают что фильм находится внутри контейнера или зашифрованного диска.
Вывод:
Злоумышленник имеет большие ресурсы. Доступ к зашифрованным данным "прямым" методам получить не удалось. Требуется доказать присутствие данного фильма в зашифрованном контейнере или диске для того чтобы далее по сценарию пошёл пиар борьбы спец. служб РФ с пиратством и сыграл свою роль в ускорении вступления РФ в ВТО например.
У злоумышленника имеется копия данного фильма, что учитывая большие размеры исходных данных даёт ? Неплохую? Возможность провести атаку на основе большого кол-ва открытого текста.
Вопрос:
Какова Ваша оценка и как Вы оцениваете вероятность доказательства последовательности бит в криптоконтейнерах?
(С учётом того что имеется только том PGP либо TC и большое кол-во открытой)
P. S. Не расшифрования, а именно доказательства, что данная последовательность бит присутствует (с высокой вероятностью достаточных например для доказательства вины в суде) в зашифрованных данных.
P. P. S. Все герои и персонажи вымышлены, похожие ситуации в жизни – чистое совпадение :-)
комментариев: 11558 документов: 1036 редакций: 4118
Ну, сценарий — так себе: борьба с видео-пиратством не входит в сферу компетенции отечественных спецслужб. Соответственно, и процессуальная значимость всех этих прослушек будет под большим вопросом. А вот если пользователь тащит с режимного предприятия, где трудится штатным инженером, спецификации секретных изделий, хранит эти данные в криптоконтейнере, а потом сливает через P2P-сеть заокеанским товарищам по договорной цене, это уже "совсем другая тема".
Касаемо вопроса, смотрите эти обсуждения. Если блочный шифр программы оперирует в ненадлежащем режиме (вроде CBC), такая атака абсолютно реалистична. Однако, против последних версий названных программ (использующих LRW) она не пройдёт.
комментариев: 1515 документов: 44 редакций: 5786
криптофс она не пройдёт (их специально так дизайнят, чтобы были устойчивы к вотермаркингу).
+ даже вотермаркинг обычно как я знаю оперирует с другими понятиями: существует
такой файл, что засунув его на криптофс можно доказать его существование там –
это типичная атака. А чтоб в качестве такого спецфайла юзать заданный – это сложнее...
комментариев: 9796 документов: 488 редакций: 5664
Как стандарт дискового шифрования LRW был отвергнут The IEEE Security in Storage work group SISWG.
Причина в том, что если в режиме LRW зашифровать сам ключ шифрования (т. н. второй tweak ключ), то существует маловероятная атака, способная тем не менее восстановить этот ключ. Это сделает шифрованием таким же ненадёжным, как ECB.
Это актуально для криптосвопов и операционных систем с полным шифрованием диска, где утечка ключа из памяти в своп считается неустранимой.
Другая атака основана на поиске коллизий в tweak-ключе, что может помочь подменять данные также легко как в ECB-режиме
(( http://grouper.ieee.org/groups/1619/email/msg00588.html Обсуждение атак было здесь ))
комментариев: 11558 документов: 1036 редакций: 4118
Особенно реалистично в ОС с поддержкой спящего режима (hibernation): ключ будет либо выгружен на диск в открытом виде, либо будет зашифрован сам собой.
Какова вкроятность успешно проведенной атаки, от чего она зависит, в общих чертах принцип атак, и придумана ли стойкая замена?
И огромное спасибо, за то, что вы один из немногих в рунете, кто часто пишет об актуальных и интересных вещах в криптографии и при этом на понятном языке )))
комментариев: 9796 документов: 488 редакций: 5664
http://ieee-p1619.wetpaint.com/
Хотя работу самой группы критиковали создатели стандарта LRW, тем не менее с ними стоит ознакомиться.
Замена LRW-AES – XEX-AES, проект стандарта здесь:
Обсуждение здесь:
http://grouper.ieee.org/groups/1619/email/msg01369.html
Недостатки LRW в целом не очень критичны, он разрабатывался известными криптографами и изучался в течении многих лет. XEX-AES – совершенно новый режим.
комментариев: 9796 документов: 488 редакций: 5664
Вам спасибо за внимание, кстати тема про уязвимости LRW-AES буквально не старше года, поэтому единого мнения по её поводу нет, последние объявления об обновлении стадартов появились вообще 9 мая 2007 года.
комментариев: 9796 документов: 488 редакций: 5664
Переводить всё нет вреемени, но вкратце: если единственная модель угрозы – разовое похищение шифрконтейнера, то все режимы стойкие, даже CBC (наверное имеется ввиду правильный CBC-ESSIV, который защищает от watermarking). Если нужна защита от измения блоков шифртескста с неким умышленным результатом, отличным от случайного или если противник может наблюдать разные версии одного и того же контейнера (при этом будет мизерная, но всё же утечка данных), то просто не храните копии контейнеров, зашифрованных на один ключ (но не пароль) и храните только локально, не храните их на удалённом хосте.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 100 документов: 49 редакций: 14
А при использовании ключевого файла в TC-томе и безопасного хранения ключевого файла, а тома удалённо?
комментариев: 9796 документов: 488 редакций: 5664
Эти атаки направлены не на извлечение ключа шифрования, а на поиск утечек информации об известном открытом тексте (или небольших текстов методом подбора).
Если злоумышленник примерно знает что и где лежит в контейнере и он же может на удалённом хосте подменять блоки шифртекста, то он может изменить целенаправлено биты в одном блоке. Например подменить запись в базе данных в ограниченном масштабе, но неслучайным, а целенаправленным образом.
А если у противника есть несколько копий одного и того же контейнера, но сделанных в разное время, то ему легче определить что там и поискать утечки хотя бы единичных битов пусть и с исчезающе малой вероятностью.
Лучше поступить так: иметь два контейнера. Один – рабочий. Другой – резервный. Оба зашифрованы на разные ключи. Когда делается backup, то информация из первого синхронизируется на второй, который и копируется на все удалённые и резервные носители. Копия должна быть побайтово одинаковых для всех носителей. После этого можно продолжать работать с основым контейнером.
Но это всё оффлайновая схема. Когда противник придёт за контейнерами он увидет одни рабочий и один запасной, одинаковый на всех носителях.
(При утрате носителей запасной надо пересоздавать).
Для онлайн схемы с недоверенным хостом это не подойдёт.