id: Гость   вход   регистрация
текущее время 13:00 29/03/2024
Автор темы: Serghan, тема открыта 08/05/2007 03:47 Печать
http://www.pgpru.com/Форум/ПрактическаяБезопасность/АтакиНаPgp-DiskИTruecryptНаОсновеОткрытыхДанных
создать
просмотр
ссылки

Атаки на 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. Все герои и персонажи вымышлены, похожие ситуации в жизни – чистое совпадение :-)


 
Комментарии
— SATtva (08/05/2007 20:21)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Засекли, что какой-нибудь пользователь скачивает себе пиратскую копию того самого модного фильма.

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

Касаемо вопроса, смотрите эти обсуждения. Если блочный шифр программы оперирует в ненадлежащем режиме (вроде CBC), такая атака абсолютно реалистична. Однако, против последних версий названных программ (использующих LRW) она не пройдёт.
— spinore (08/05/2007 22:14)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
То есть то что вы описали есть атака вотермаркинга, и для нормально имплеменченных
криптофс она не пройдёт (их специально так дизайнят, чтобы были устойчивы к вотермаркингу).
+ даже вотермаркинг обычно как я знаю оперирует с другими понятиями: существует
такой файл, что засунув его на криптофс можно доказать его существование там –
это типичная атака. А чтоб в качестве такого спецфайла юзать заданный – это сложнее...
— unknown (10/05/2007 09:12, исправлен 10/05/2007 09:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Не совсем по теме:

Как стандарт дискового шифрования LRW был отвергнут The IEEE Security in Storage work group SISWG.

Причина в том, что если в режиме LRW зашифровать сам ключ шифрования (т. н. второй tweak ключ), то существует маловероятная атака, способная тем не менее восстановить этот ключ. Это сделает шифрованием таким же ненадёжным, как ECB.


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

Другая атака основана на поиске коллизий в tweak-ключе, что может помочь подменять данные также легко как в ECB-режиме



Workgroup has dropped the AES-LRW mode and replaced it with XEX-AES
-AES-LRW mode has a vulnerability when key 2 is encrypted in the medium




(( http://grouper.ieee.org/groups/1619/email/msg00588.html Обсуждение атак было здесь ))



— SATtva (10/05/2007 21:53)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Не помню всех деталей той истории, но, по-моему, LRW не был принят только из-за отсутствия полного консенсуса в рабочей группе. Но могу ошибаться.

Причина в том, что если в режиме LRW зашифровать сам ключ шифрования (т. н. второй tweak ключ), то существует маловероятная атака, способная тем не менее восстановить этот ключ.

Особенно реалистично в ОС с поддержкой спящего режима (hibernation): ключ будет либо выгружен на диск в открытом виде, либо будет зашифрован сам собой.
— Гость (10/05/2007 22:04)   <#>
unknown, если не очень сложно, можно немного поподробнее, из обсуждения по ссылке я, к сожалению многого не понял.

Какова вкроятность успешно проведенной атаки, от чего она зависит, в общих чертах принцип атак, и придумана ли стойкая замена?

И огромное спасибо, за то, что вы один из немногих в рунете, кто часто пишет об актуальных и интересных вещах в криптографии и при этом на понятном языке )))
— unknown (11/05/2007 09:16)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Все материалы по проекту стандарта p1619 здесь:

http://ieee-p1619.wetpaint.com/

Хотя работу самой группы критиковали создатели стандарта LRW, тем не менее с ними стоит ознакомиться.

Замена LRW-AES – XEX-AES, проект стандарта здесь: filehttp://grouper.ieee.org/groups/1619/email/pdf00037.pdf

Обсуждение здесь:
http://grouper.ieee.org/groups/1619/email/msg01369.html

Недостатки LRW в целом не очень критичны, он разрабатывался известными криптографами и изучался в течении многих лет. XEX-AES – совершенно новый режим.
— unknown (11/05/2007 09:19, исправлен 11/05/2007 11:14)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
И огромное спасибо, за то, что вы один из немногих в рунете, кто часто пишет об актуальных и интересных вещах в криптографии и при этом на понятном языке )))

Вам спасибо за внимание, кстати тема про уязвимости LRW-AES буквально не старше года, поэтому единого мнения по её поводу нет, последние объявления об обновлении стадартов появились вообще 9 мая 2007 года.
— unknown (11/05/2007 12:19, исправлен 11/05/2007 12:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вот еще обсуждение по поводу утечки данных в разных режимах

Переводить всё нет вреемени, но вкратце: если единственная модель угрозы – разовое похищение шифрконтейнера, то все режимы стойкие, даже CBC (наверное имеется ввиду правильный CBC-ESSIV, который защищает от watermarking). Если нужна защита от измения блоков шифртескста с неким умышленным результатом, отличным от случайного или если противник может наблюдать разные версии одного и того же контейнера (при этом будет мизерная, но всё же утечка данных), то просто не храните копии контейнеров, зашифрованных на один ключ (но не пароль) и храните только локально, не храните их на удалённом хосте.
— unknown (11/05/2007 12:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
fileВот ещё очень хорошая и подробная презентация про дисковое шифрование
— Гость (12/05/2007 02:41)   <#>
Еще раз спасибо за интересную инфу.
— Serghan (14/05/2007 03:38)   профиль/связь   <#>
комментариев: 100   документов: 49   редакций: 14
unknown:
только локально, не храните их на удалённом хосте

А при использовании ключевого файла в TC-томе и безопасного хранения ключевого файла, а тома удалённо?
— unknown (14/05/2007 09:23, исправлен 14/05/2007 09:37)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А при использовании ключевого файла в TC-томе и безопасного хранения ключевого файла, а тома удалённо?

Эти атаки направлены не на извлечение ключа шифрования, а на поиск утечек информации об известном открытом тексте (или небольших текстов методом подбора).

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

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

Лучше поступить так: иметь два контейнера. Один – рабочий. Другой – резервный. Оба зашифрованы на разные ключи. Когда делается backup, то информация из первого синхронизируется на второй, который и копируется на все удалённые и резервные носители. Копия должна быть побайтово одинаковых для всех носителей. После этого можно продолжать работать с основым контейнером.

Но это всё оффлайновая схема. Когда противник придёт за контейнерами он увидет одни рабочий и один запасной, одинаковый на всех носителях.
(При утрате носителей запасной надо пересоздавать).

Для онлайн схемы с недоверенным хостом это не подойдёт.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3