id: Гость   вход   регистрация
текущее время 08:54 24/08/2019
Владелец: ressa (создано 25/10/2013 18:54), редакция от 26/10/2013 11:41 (автор: SATtva) Печать
Категории: криптография, уязвимости, исходные тексты
https://www.pgpru.com/Новости/2013/АудитСборкиTrueCrypt71aНеВыявилРасхожденияСИсходнымиТекстами
создать
просмотр
редакции
ссылки

25.10 // Аудит сборки TrueCrypt 7.1a не выявил расхождения с исходными текстами


Опубликованы результаты результаты сравнения официальной бинарной сборки TrueCrypt 7.1a для Windows и сборки, сформированной собственными силами из исходных текстов. Анализ различий показал, что в официальная бинарная сборка не содержит скрытых функций и тождественна поставляемым исходным текстам. Разница наблюдается только в элементах, связанных со сборочным окружением и используемыми на этапе компиляции опциями.


Исследование показало, что правильный подбор используемых при сборке инструментов, воссоздающий оригинальные условия сборки, позволяет сформировать тождественный исполняемый файл и подтвердить, что в распространяемые производителем бинарные сборки не были внесены скрытые изменения. Таким образом удалось подтвердить отсутствие скрытых модификаций без необходимости выполнения трудоёмких операций по обратному инженерингу исполняемых файлов. В настоящее время, усилия по аудиту проекта TrueCrypt могут сосредоточится на изучении исходных текстов и методов шифрования, .


Кроме того, представителям проекта IsTrueCryptAuditedYet удалось связаться с авторами TrueCrypt, которые приветствовали идею проведения независимого аудита безопасности их продукта. Напомним, что в рамках проекта IsTrueCryptAuditedYet создана инициатива для подтверждения отсутствия в TrueCrypt проблем безопасности и скрытых бэкдоров. Одним из подозрений было отсутствие гарантии, что бинарные сборки, которые составляют основную массу загрузок, не содержат закладок и собраны на основании публично доступного исходного кода без внесения скрытых изменений.


Источник: http://www.opennet.ru/opennews/art.shtml?num=38259


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии [скрыть комментарии/форму]
— Гость (13/11/2013 22:27)   <#>
Таким модераторам по большому памятники ставить надо.
— Гость (13/11/2013 22:57)   <#>

Честно говоря, я считаю ваш пример натянутым. В вашем случае, когда вы/мы/остальные лезем во внутренности TBB, это на чём-то неминуемо сказывается. Знаете, можно было бы сильно упростить мою инструкцию, если написать драйвер, позволяющий работать на запись с обоими разделами одновременно (и скрытым и нескрытым), но я ведь не зря отказался от этой затеи. Возможно, от теоретических предпосылок до практической эксплуатации там как до Луны пешком, но мне заранее понятно, что это нельзя сделать идеально, и я решил проблему с перхотью проще: отрубил голову.

Загрузка с внешнего носителя, который нужно каждый раз затирать, запрет на изменение данных во внешнем обманном разделе, необходимость время от времени вручную пересоздавать разделы и данные на них, неудобство — это та цена, которая платится за универсальность и идеальность. Т.е. решение всех спорных вопросов я решил за счёт потери удобства. Для Tor Project'а такой подход немыслим, там неминумо будут компромиссы, и то, что вы делаете — это заранее какой-то компромисс, вы сами же в этом сознавались. И я полностью с вами согласен, что в вашей схеме быть идеально уверенным трудно, хотя что-то гарантировать всё же можно (к примеру, запрет файерволлом соединений в обход Tor).


Может быть, не все ещё до конца поняли, но никаких свободных разделов нет. Есть разделы, но все они отформатированы и «заняты». На файловых системах этих разделов хранятся, пардон, файлы. Да, файловые системы забиты не битком, на них есть свободное место. Это значит, что свободное место есть на разделе. Вот в это свободное место мы и пишем скрытые данные. Наличие не до конца заполненных файловых систем тут ещё не предлагали крминализовать? Кстати, даже без всякой отрицаемости естественным образом скапливаются архивы, которые годами некогда посмотреть и разгрести. Свободное место в разделах, на которых эти архивы хранятся — неплохой кандидат для использования в качестве скрытого.


Вообще-то каждый проход записи на многогигабайтный диск — это время, время и ещё раз время. Минимум — один раз пройтись чем-то (надёжней рандомом, чем нулями). IMHO, это объяснение получается совершенно естественным.


Своп, шифрованный статическим ключом? Вот этот статический ключ и заставят предъявить. Или вы хотите сказать, что ключ там статический, а вы будете говорить, что он генерировался динамически, и вы его, естественно, не знаете? По-моему, это явно менее отрицаемо, чем то, что я предложил. :) Это не сильно отличается от случаев типа «забыл пароль» или «никогда его не знал, потому что <подставить нужное>».


Я принципиально не использую выделенные разделы. Я предлагаю использовать свободное место на файловой системе, превращая его в логический раздел через dmsetup. Пустые разделы, IMHO — куда большее паливо, и объяснение их существованию вида «создал, но не стал использовать», тоже не очень правдоподобно.


Вот! Цель достигнута. :-) Анонимность невозможна без массовости, так и тут: правдоподобное отрицание невозможно без массовости присутствия «косвенных улик» у всех и каждого. Кстати, объяснение может быть и другим: да, использовал шифование, был полный диск данных, потом оно мне стало ненужным, я заново переформатировал диск и установил новую ОС. Случайные данные в неиспользуемых местах остались от ранее использовавшего шифрования. Пароль вот он: <xxx>. Не подходит? А к чему он, по-вашему, должен подойти, если при инсталляции новой ОС заголовкок старого контейнера мог затереться новыми данными, что делает знание старого пароля полностью бессмысленным?

P.S. По-моему, есть одна важная мысль, которая до людей здесь не доходит. Ценность в схеме в том, что она абсолютно универсальна. Правда, здесь нет моих заслуг, это тривиальный факт, а по сути — основное назначение dmestup. Если у вас есть прямая адресация дискового пространства, которая не имеет сигнатур и ни от чего не зависит, то вы можете делать всё, что угодно:

  • Вам не нравится openssl, он оказался уязвимым? Поставьте любой другой встроенный в систему тул, которые умеет шифровать без сигнатур (возможно, с костылями).
  • Вам не нравится наличие высокоэнтропийных данных в свободных местах диска? Отлично. Забейте раздел на 70% какими-нибудь файлами, 40% из них потом сотрите, потом снова запишите какие-нибудь файлы, снова сотрите, и так раз 20. Потом прочитайте поблочно диск (размер блока определяете сами) и смотрите, у какого блока какая энтропия. Часть блоков с высокой энтропией вносите в БД dmestup. Дальше по накатанной... Косвенные признаки, не спорю, могут быть и в такой схеме, но она будет практически за пределами того, что сейчас можно проанализировать. Да, вы восстановите какие-то файлы, какие-то не восстановите, ну и что? Это нормальная ситуация для использумой ФС, с которой трут данные и на которую пишут новые. Возьмите даже куда более простую идеализированную задачу: вам дан кусок файла (не сначала и не с конца), который принадлежит архиву, видео и шифртексту. Определите, кому он принадлежит. Теоретически задача как бы имеет намёки на решаемость, а практически тут всё очень туго. А если таких кусков много, они перемешаны, не ясно, кому принадлежат...

Да, получается, в каком-то смысле, безопасность через неясность усложнение и запутывание, но и Tor ведь идёт с обфускацией по точно тому же пути. Наша цель — поднять затраты на анализ диска. Даже одно то, что эксперту придётся вручную месяцами сидеть и разбирать этот мусор, будет означать то, что в 999 из тысячи случаев никто не захочет этим заниматься. А когда появится конкретный тул для анализа, можно устроить гонку вооружений. Раз нет у задачи абсолютного решения, достаточно быть не идеальным, а просто на шаг впереди: использовать такую схему, анализ которой себя не окупает. Как было неоднократно замечено в других тредах форума, даже тупое наивное отсечение стандартизированных средств анализа в подавляющем большинстве случаев решает проблему, а если там будет ещё и что-то оригинальное и хоть как-то обоснованное (то, что предлагается здесь), то ещё лучше.
— unknown (14/11/2013 10:08, исправлен 14/11/2013 10:09)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я дал кривые ссылки, по которым неудобно читать всю дискуссию. Прочитайте всю тему здесь. Обратите внимание на это сообщение. Сравните его с вашей схемой, хотя у вас она конечно более навороченная. Обратите внимание на аргументы, выдвинутые против подобных схем разработчиком Арно Вагнером в дискуссии далее.


По мне — этих аргументов против достаточно, по вам — нет. Вот и вся разница, а так все всё понимают и идея витала в воздухе лет десять, в общем виде известна.

— Гость (14/11/2013 10:45)   <#>
Менять удобный гуй трукрипта на командную строку cryptsetup или tc-play – это просто фейспалм во все поля. Красноглазики почему-то никак этого понять не могут, когда начинают причитать "truecrypt не нужен, монтируйте контейнеры набивая пути к ключам по полчаса". Особенно если включена история (а она по-умолчанию почти всегда включена) команд.
— unknown (14/11/2013 11:07, исправлен 14/11/2013 11:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Будет вам GUI сразу для всех трёх. В Гноме и ещё где-то для LUKS можно монтировать, просто щёлкая по иконкам. Хотя для красноглазиков GUI — это сразу -100 к безопасности.



HISTIGNORE забейте по шаблону. Хотя, зачем? С историей же наоборот набирать быстрее. Или вы думаете, что отключив историю, вы скроете факт обращения к дискам? Он всё равно оседает в куче логов, даже если вы открывали эти диски через GUI.

— Гость (14/11/2013 11:45)   <#>
У Трукрипта с последним будет уже минимум два независимых аудита, не говоря про репутацию. А у зулуса этого что за плечами? GPL? Маловато как-то.

Не к дискам, а пути к ключевым файлам и их названия будут.
— unknown (14/11/2013 12:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Взаимодополняющие параграфы :)
— Гость (16/11/2013 20:55)   <#>

По-моему, оно там уже полностью есть, или нет?


Я считаю, что это существенно сужает область применимости TC mode, раз всё равно придётся ставить TC для того, чтобы воспользоваться TC-специфичным функционалом.


Для отрицаемости я бы обратил внимание не на TrueCrypt mode, а на plain mode. Последний man cryptsetup есть, например, здесь. Наверное, plain mode — это и есть то, о чём сказано в /comment45000:

LUKS можно не использовать, а задавать сразу master key

Судя по man cryptsetup, при использовании plain mode никаких заголовков нет (хотя можно использовать внешний ключевой файл, если кто пожелает, или иметь LUKS-заголовок во внешнем файле). Кроме того, есть следующие полезные опции:

--size, -b <number of 512 byte sectors>
Force the size of the underlying device in sectors of 512 bytes. This option is only relevant for the open and resize actions.
--offset, -o <number of 512 byte sectors>
Start offset in the backend device in 512-byte sectors. This option is only relevant for the open action with plain or loopaes device types.

Складывается впечатление, что цирк с openssl magic не нужен, а всё необходимое уже есть в cryptsetup: берём любое блочное устройство с нарезанной на нём файловой системой и данными; находим свободное место; вычисляем размер этого места и его оффсет относительно начала блочного устройства; передаём эти данные cryptsetup, указывая всё блочное устройство целиком, как target device; и, собственно, всё. Было бы лучше, если б заголовок был, но он шифровался чем-то стандартным (как в TrueCrypt), но и plain mode уже номинально достаточна для отрицаемости.

По ссылке unknown'а:

Because TCRYPT header is encrypted, you have to always provide valid passphrase and keyfiles.

А что, если опечатаюсь? Поидее проблем быть не должно — просто при попытке монтирования будет ругань на неопознанную файловую систему, но на сам раздел ничего записано не будет, информация в контейнере не исказится. Так ведь?

Change LUKS default cipher to to use XTS encryption mode, aes-xts-plain64 (i.e. using AES128-XTS).

А почему AES128-XTS, а не AES256-XTS?

Почитал параграф в man под названием

NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE

Мне кажется, что в plain mode при машинной генерации паролей (мастер-ключей) нет смысла использовать нетривиальный --hash (разве что для защиты от атакующего, наблюдающего за вводом пароля — вдруг не все символы запомнит?) — лучше подобрать правильную длину и всегда указывать --hash plain.
— unknown (16/11/2013 21:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Почти везде так, даже в OpenSSL.
— Гость (16/11/2013 22:24)   <#>
Но ведь рекомендуемое -c aes-xts-plain64 -h sha512 -s 512 всё-таки соответствует AES256-XTS, разве нет? И 256 лучше, чем 128, поэтому, раз они решили сменить дефолт, почему бы не сменить его на самый лучший?
— unknown (16/11/2013 22:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Старый принцип: больше размер ключа — медленнее шифрование, хотя сейчас это уже жалкие доли процента, но может кто-то будет использовать на старых и медленных компьютерах.

На компах конца 90-х шифрование на десктопе отнимало процентов 20, параметры ключа были важны: избыточно большой ключ старались не выбирать. Сейчас это может быть актуально на каких-нибудь тормозных гаджетах.
— Гость (24/11/2013 03:51)   <#>

Прочитали. Ниже представляю полный разбор этой, этой, этой и других дискуссий попорядку.


I'd like this as well... but wouldn't it be counter productive to officially support plausible deniability?

My vote is for plausibly deniable support for plausible deniability... seriously.

Это, как и ваш комментарий

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

заставляют задуматься. Серьёзные люди говорили:

Несколько человек его настоятельно рекоменодвали не публиковать в открытом доступе или, по крайней мере, не описывать все детали

Это ставит вопрос о том, должно ли правдоподобное отрицание реализовываться общеизвестными способами или всё-таки самопальными костылями? Уменьшит ли отрицаемость её добавка в cryptsetup? Если схема известна и растиражирована, будет ли она давать меньшую отрицаемость? Цитата

But that it is even possible with cryptsetup is already advanced knowledge, while with TrueCrypt it is an openly advertized feature.

тоже немкает на принцип медведя, т.е., что есть разница между «openly advertized» и «advanced knowledge feature/misuse».

cryptsetup is low level tool, most of features are expected to be build on top of it

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

The longer story is that if you use a hidden volume, you either have to make the filesystem in the container smaller (to protect the hidden volume from being overwritten), which is blatantly obvious, or you have to refrain from using the actual outer container, which again is pretty obvious.

В предложенной схеме нет этих проблем. Авторы держат в голове устаревшую схему TrueCrypt, содержащую множество изъянов, и мысленно критикуют именно её, а не весь набор всевозможных конструкций отрицаемости. Автор пишет, что обманная ФС (или контейнер) либо должна быть малозаполненной, либо не использоваться, чтобы не затереть скрытые данные. С первым всё очевидно: предлагаемая схема не вносит никаких ограничений на тот процент, который должна занимать обманная ФС. Со вторым тоньше, но ответ тоже на поверхности: если придерживаться предложенного регламента, то всё, что увидит атакующий — это то, что обманная ФС не менялась последние сколько-то дней/недель/месяцев. Никаких других отличительных признаков на ней нет: даты создания файлов разные, создавалось всё самым естественным образом, потом могло многократно меняться и т.д. Да, после того, как создали скрытый раздел, изменения в обманке возможны, только если параллельно производится полное пересоздание скрытого раздела и полная перезапись файлов в него. Каждый может подумать сам, какой срок отсутствия изменений в данных вызывает подозрения, а какой нет, стоит ли заблаговременно сделать изменения, если предстоит пересечь границу неблагоприятного государства и т.п. Даже без всякого отрицания естественным образом почти у каждого накапливаются архивы не особо чувствительных данных, которые меняются очень редко.

Well, not "open plain directly visible" like the LUKS header. More like pretty clear that something encrypted is in there if somebody competent checks. And there will be the TrueCrypt software on the sytem disk with most users, possibly even with the partition to mount still remembered. But I agree, calling this "open" is not fair. But I would not say it really qualifies as "hidden" either. Maybe "opaque".

Именно поэтому отсутствие специфичного софта было взято как основное требование, а равно и отказ от работы со скрытыми и обманными разделами из-под одной и той же ОС. Обманка должна работать исключительно с внешнего LiveCD/LiveUSB-носителя, который не сохраняет никаких следов своей работы где-либо помимо скрытого раздела.

You should be able to get away with hiding a few MBs that way, e.g. by using cylinder-aligned partitions and puttong the hidden volume between them or at the end of the disk.

Я не понял, что они предлагают. Они хотят сказать, что есть такие относительно традиционные разбиения дисков, при которых всё равно остаётся несколько мегабайт свободного места, и вот его-то и можно будет использовать?

Even then, the crypto-blanking can be enough of a hint to make the approach fail in practice.

Как уже было сказано выше в этой ветке, есть множество вполне разумных объяснений того, зачем был сделан предварительный «crypto-blanking», поэтому hint неубедителен.

For example, if law enforcement can force you to hand over crypto-keys, they are already ignoring the fact that you can forget them.

Это неправда. У стороны обвинения должны быть убедительные доказательства того, что подозреваемый
  1. Имеет скрытые разделы.
  2. Обладает возможностью их открыть.
То, что ему «разрешено забыть», ничего не меняет: фича остаётся полезной, если забывчивость будет считаться судом менее убедительной, чем отсутствие скрытых данных. Т.е. забытие пароля и отрицаемость — почти ортогональные понятия, незачем их смешивать.

When the attacker has the power to ignore facts, no amount of logical reasoning is going to help you.

Следуя такой логике, можно вообще отказаться от шифрования. Если противник применит бандитский криптоанализ, то уже ничего не поможет, поэтому зачем шифровать диски?

The only real protection (once competent forensics people are looking at your set-up), is to provably have no secret data.

То же самое можно сказать и про обычное шифрование. Вместо того, чтобы искать пути решения проблемы (чай мы тут не защиту от копирования изобретаем; пока ещё никто не доказал, что отрицаемое шифрование невозможно), автор предпочитает позицию страуса — отрицать возможность её решения или приводить аргументы ad absurdum. А вы думали, в рассылках не бывает троллей?

Crypto is for access control, not for hiding things.

Computer is for access control, not for safe data encryption. Ad absurdum — такой, с ним не поспоришь (side channels attacks в свидетелях).

you have to refrain from using the actual outer container, which again is pretty obvious.
You are preceded by TC who supposedly already solved these issues. At least analyze TC's method before assuming there is no correct method.

Люди палятся на незнании того, как работает TC, в случае которого высказанная претензия действительно справедлива.

btw the link above uses fixed header size. that's wrong. always check payload size of size of header backup – it depends on key size, it can differ from that example

Разве у хидера переменный размер? Или переменный размер бывает только у внешнего файла, куда экспортируют хидер?

any good idea can be used for bad.

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

I've been thinking about a funny idea for plausible deniability.
...
You could use it as such:
...
All in all, it's a pretty sweet setup, and all it needs is that modified loopback device, which doesn't yet exist.

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

I was looking at scubed recently (http://cube.dyndns.org/~rsnel/scubed/) and was wondering if something similar might be an option.

Наверно, ссылка померла окончательно. У меня при заходе браузер пытается скачать Apple Quick Time файл на несколько байт. Что было по ссылке на самом деле, теперь можно судить только по архиву. Вроде ничего интересного.


Bash's HISTIGNORE might be what you're talking about. With it, you can specify in your personal or system Bash profile that commands matching certain patterns won't go into the history.

Детский сад, что у вас, что в рассылке. Следов в системе — полные штаны. Кто вам запрещает создать /tmp как tmpfs в памяти и указать в конфиге шелла писать историю в файл на /tmp?

I don't see how legally a court could imprison somebody indefinitely merely on unproven suspicion that multiple aspects of some data exist.
Ha! Tell that to H. Beatty Chadwick.

Очень показательная ссылка. :-)


По ссылке:

since truecrypt also uses a header,assuming the same use cases and with the same number of users, will truecrypt volume's header be corrupted at the same rate luks headers will?

Not exactly the same, because there is a backup header. But because backup header is located near the end of device, it adds different problems with device resize. Backup header is double-edged sword (both from security and code maintenance POV).

Cryptsetup can use backup header, but you need to say this explicitly with parameter. There is no autorecovery (cryptsetup will never touch Truecrypt header – all operations are read-only, at least for now.)

Звучит так, как будто у TC есть бэкап хидера, и этот бэкап хранится в конце раздела, а у LUKS бэкапа нет, и его хидер — только в начале. Unknown, не поторопились ли вы с заявлением «в новом формате LUKS заголовок имеет копию в конце тома, поэтому смысла затирать его через urandom нет»?

На тему будущего поддержки TC в LUKS единого мнения среди разработчиков нет. Вот, например, один смотрит на это достаточно позитивно и не исключает добавления прочих TC-возможностей:

Also,cryptsetup 1.6.0 added supported for opening of truecrypt volumes but nothing is currently mentioned on adding support for creating of truecrypt volumes. Is the support planned at some point in the future?

It depends. It can be done in future. But the real reasons I did not implement it (except lack of time):
  • I want to see real users (of already formatted device) before investing time to any foreign format or key change operation
  • I do not want to cannibalise LUKS which is now de facto standard for Linux FDE, Truecrypt format support was meant to simplify easy data sharing with other OS-encrypted disks (without need to instal 3rd party sw), not full replacement (and there is tcplay already). Implementing is just part of it, there must be some support to stabilise it, fix user problems, create knowledge base... (BTW if anyone have open documentation for other FDE systems, like Bitlocker or Endpoint encryption, let me know please... :)
  • It was experiment if userspace kernel crypto API is usable for this kind of application, also it was kind of research for older truecrypt header format and features.

Но другой (разработчик?) пишет:

Is the support planned at some point in the future?
I don't think so. See above. Seriously, if you want to create a TrueCrypt volume under Linux, use the TrueCrypt tools, not cryptsetup


Люди пишут о том же:

It is based solely on the documentation available on the TrueCrypt website, many hours of trial and error and the output of the Linux' TrueCrypt client. As it turns out, most technical documents on TrueCrypt contain mistakes, hence the trial and error approach.

и

Bugs in the TrueCrypt documentation

The TrueCrypt documentation is pretty bad and does not really represent the actual on-disk format nor the encryption/decryption process.

Some notable differences between actual implementation and documentation:

  • PBKDF using RIPEMD160 only uses 2000 iterations if the volume isn't a system volume.
  • The keyfile pool is not XOR'ed with the passphrase but modulo-256 summed.
  • Every field except the minimum version field of the volume header are in big endian.
  • Some volume header fields (creation time of volume and header) are missing in the documentation.
  • All two-way cipher cascades are the wrong way round in the documentation, but all three-way cipher cascades are correct.


Его метод:

3. luks doesnt support hidden volumes.

It does, in a way.

Create a loop file (or an existing partition).
fill it with random data (important!)
cryptsetup luksFormat it
cryptsetup luksOpen it
Format the crypted device with FAT32 (important!)

Then, use loop with a high offset, e.g. more than half of the disk,
create a plain cryptsetup
losetup -o 10000000 device
cryptsetup create loop secretname
format it with any filesystem, copy your very secret documents in it, close this partition.

By doing this, anyone without the knowledge of the offset + the password won't be able to prove that you have datas hidden. Warning, if you write more data in the first luks device than the offset choosen, you destroy data (but in some case, you may want it).

True. Not much worse than the TrueCrypt variant actually.

Это не моя схема (или если и моя, то явно не из последних). То, что предлагает автор, на уровне абстракций идентично тому, как это делает TC, а у меня к отрицаемости в TC есть вполне конкретные претензии (помимо собственно того, что ранее требовалось устанавливать сам TC, что ещё один минус к отрицаемости).

TrueCrypt does not do any better here.
Truecrypt helps here: If you know both password (normal + hidden) container, you have a mode where you can't overwrite your hidden datas, it helps for safety of hidden datas.
Not really. First, it returns an error on write access to the hidden container. That is bound to leave filesystem annomalies and possibly even log-entries. Second, as it returns an error, reliable use of the outer container is not possible anymore.

Получается, что при вылезании за пределы отведённого объёма теряется как защита от повреждений, так и отрицаемость (ошибки попадут в системные логи)?

That means once you open the container for them, all unused space is zeros or at least low entropy.

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

Bottom line is that you are only safe if you do not have an encrypted container when going into a situation where suspicion could fall on you.

Предлагаю потроллить рассылку перлами:
  • You are only safe if you do not have a computer.
  • You are only safe if you do not have an edication in IT.
  • You are only safe if you do not have a <подставить нужное>.
Чем мой троллинг толще их троллинга?

То, что они предлагают (пересекать границу без шифрованных данных, а потом выкачивать их из интернета), как минимум, не отвечает на вопрос, как безопасно хранить эти данные дома. Всё держать в облаках? Очень смешно, ага. То, что «скачать на новом месте из интернета» можно только ограниченный объём (ну не терабайты же качать), эти советчики тоже не учитывают. А если граница пересекается не так редко? Каждый раз по терабайту качать?

Проще тогда этой методике следовать: данные в два этапа провозить и шифровать их одноразовым блокнотом. Первый раз везём два диска: на одном гамма, на другом шифртекст, соответствующий обманным данным. Если к гамме претензий не возникло, следующий раз везём шифртекст с настоящими данными и подставной ключ к ним, который бы их расшифровывал во что-то нейтральное.

И, да, я согласен с троллями, что ездить без шифрованных данных (а лучше вообще без компьютера и носителей информации) со всех сторон безопасней и даёт лучшую отрицаемость, но это не решение поставленной задачи, а уход от неё. Есть такой поучительный анекдот на тему логики:

— Как вскипятить чайник?
— Очень просто. Рассмотрим случай, когда он пустой. В этом случае, очевидно, его кипятить не надо. Теперь рассмотрим случай, когда он с водой. Решение простое: выливаем воду, и тем самым сводим задачу к уже рассмотренному случаю.

Советы троллей, как сделать отрицаемость лучше, до боли напоминают этот пример.

There are a number of legitimate reasons other than encrypted data why that high-entropy data could be there. For example, I do experiments with true-random number generators and after whitening the result is indistinguishable from encrypted data. Yet I store the results for analysis and they can be large. I also wipe disks securely by mapping them in dm-crypt with a long random key and overwriting the mapped container with zeros. No way for me to prove they were erased.

В этом и состоит отрицаемость. Раз они сами всё знают, то зачем троллят? Отрицаемость в том и заключается, что нельзя ни доказать, ни опровергнуть (косвенных улик мало, они неспцифичны, и поэтому они недостаточны даже для юридически веского доказательства).

While KISS applies, I have no objevtions to increasing complexity if there are significant security benefits. They are not there with hidden volumes or embedded volumes, as I have explained.

Эту позицию — да, можно понять.


Да, в предлагаемой схеме есть «risk of destroying them», поэтому неаккуратное обращение с обманкой испортит скрытый раздел, а аккуратное всё сохранит, не давая никаких «hint to an attacker», потому что информация о местоположении скрытого раздела не хранится в обманной ОС никаким образом. Критика автора была направлена против TC-подобной схемы, и тут я с ним согласен, что

TrueCrypt does not do any better here.


Also keep in mind that in many situations (US border inspection, e.g.) the mere suspicion of a computer being present will be enough. Если нет ссылок на реальную юридическую практику, можно троллить, как душе угодно, особенно расширяя понятие «suspicion» до полного абсурда вплоть до «виновен вообще во всём, за исключением того, в чём свою невиновность можешь убедительно доказать».

Всем известная ссылка на вики остаётся сравнительно актуальной:

Plausible deniability is also a legal concept. It refers to lack of evidence proving an allegation. Standards of proof vary in civil and criminal cases. In civil cases, the standard of proof is "preponderance of the evidence" whereas in a criminal matter, the standard is "beyond a reasonable doubt." If an opponent lacks incontrovertible proof (evidence) of their allegation, one can "plausibly deny" the allegation even though it may be true.

Вообще, если посмотреть на википедию, как некий срез общеизвестных методов, то там пишут:

Concerns have, however, been raised for the level of plausible deniability in hiding information this way – the contents of the "outer" container filesystem (in particular the access or modification timestamps on the data stored) could raise suspicions as a result of being frozen in its initial state to prevent the user from corrupting the hidden volume. This problem can be eliminated by instructing the system not to protect the hidden volume, although this could result in lost data. FreeOTFE and BestCrypt can have many hidden volumes in a container; TrueCrypt is limited to one hidden volume.

Т.е. критикуется отрицаемость именно в рамках TC. И эту TC-отрицаемость ошибочно отождествляют с общим случаем отрицаемости в дисковом шифровании. Там же про распознавание скрытых разделов:

Detection

The existence of a hidden volume may be revealed by flawed implementations relying on predictable cryptographic items or by some forensic tools that may detect non-random encrypted data. Vulnerability to chi-squared randomness test has also been suggested: encrypted data, after each write operation, should be adjusted to fit a plausible randomness property.

Deniable encryption has also been criticized because of its main inability in defending users from rubber-hose cryptanalysis. Possession of deniable encryption tools could lead attackers to continue an investigation even after a user pretends to cooperate, providing an expendable password to some decoy data.

«Non-random encrypted data» — это, наверно, что-то новое в криптографии. :-) «Predictable cryptographic items» в бессигнатурном шифровании — это тоже весело, можно сразу статью в IACR писать. «Vulnerability to chi-squared randomness test» — отличие рандома от шифрованных данных? Я ж говорю, сразу статью в J. of Crypt. можно накатать. «Possession of deniable encryption tools» — вот поэтому и нужно для отрицаемости использовать только стандартный софт, который есть у всех. «Rubber-hose cryptanalysis» и «could lead attackers to continue an investigation even after» — очередной троллинг, где бандитам приписывают либо отсутствие логики, либо ту логику, которая нравится критикователям («забьют до смерти на всякий случай» и т.д.), игнорируя не только требование иметь хоть сколь-нибудь приближённую к реальности ситуацию, но и издержки, риски бандитов и т.п. вопросы.


В /comment58759 уже упоминалась ссылка на вики-статью «Key disclosure law». Рекомендую разработчикам cryptsetup поменьше заниматься спекуляциями и побольше заглядывать в эту ссылку законодательство, больше конструктива будет.


Кажется, в связи с новостью-предшественником здесь ещё не упоминалась замечательная ссылка от 2010-2011-го, в которой автор привёл 8 пунктов против использования TC (запрет на упоминание чего-то иного TC-совместимого на официальном форуме поддержки TC веселит; TC-team уже исправлили это в правилах?). Кстати, там же:

I still recommend Truecrypt, they are my second choice of full disk encryption software after DiskCryptor.

Значит, не я один так думаю.


Виновность/невиновность в чём? Есть подозрение в X. Решили, что подозреваемый сознательно что-то скрывает и не идёт на сотрудничество. Осудили за X. Теперь, если шифрования нет, выглядит так: подозревали в X, поглядели в компьютер, получили доказательства вины в X, Y, Z... Что выгоднее, шифровать или не шифровать? Вопрос риторический.


Мне не трудно показать вам ссылки на обсуждения этой проблемы, которые здесь велись лет 10 назад, а также на ваши посты в этих обсуждениях, чтобы спросить, где же та самая идея витала, а то десятки обсуждений, и ноль продуктива, всё ломается, всё неидеально, всё оставляет следы. В общем-то виде оно как бы понятно, чего хочется, но что толку от этого, если нет способа реализации? Давайте начнём с простого:

  1. Скажите, как это сделать в современной OpenBSD. Я вот не знаю, честно. Device mapper'а там нет, а традиционные дисковые разделы недостаточны хотя бы по тем причинам, что
    1. Пустое неразмеченное неиспользуемое место на диске плохо отрицается.
    2. Нельзя использовать неразмеченное дисковое пространство.
    3. Таблицу дисковых разделов нельзя хранить где-то ещё помимо собственно целевого диска (нельзя кормить ядро информацией извне).
    4. Если ядро подцепило разделы с диска и работает с ними, а мы потом меняем таблицу разделов на диске, ОС зависает через несколько секунд (kernel-хакреы предлагали писать надёжный rootkit для скрытия отрицаемого шифрования и надеяться, что в логах ядра ничего подозрительного не вылезет, т.е. никакого более простого решения они не видели; и даже в этом случае ситуация сводится к исходной: как скрыть модифицированное ядро? Где его хранить?).
  2. Как реализовать отрицаемость в GNU/Linux без использования dmcrypt? Он ведь в GNU/Linux не с момента первого публичного релиза как бы (кстати, кто-нибудь знает, когда он там появился?).


Ага, он знатно потроллил, но его можно понять: ему не хочется поддерживать те фичи и сложности, которые лично ему и на данном этапе его жизни неинтересны.


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


Не согласен. Во-первых, никаких новых аргументов я там не увидел. Все эти вопросы, опасения и пр. уже обсуждались, обдумывались, решались здесь. Ничего существенно нового и интересного, что я бы узнал из этих ссылок, нет. Единственное исключение — вот этот не очень внятный пост, но об этом ниже.

Если подвести итог под всеми этими дискуссиями в рассылках, складывается примерно следующая картина:
  1. Поначалу, когда авторы cryptsetup были более расположены к обсуждению и внесению изменений, юзеры предлагали всякую чушь. Им на эту чушь отвечали, что это чушь. Много постов было откровенно ламерских, и разрабы от этих дискуссий в итоге откровенно устали. Редкие полезные мысли и посты тонули в потоке бреда и топтания на месте (каждый, кто изобретает отрицаемое крипто, по сто раз ломает собственные изобретения, пока не прийдёт к чему-то более-менее обоснованному, выведя для себя определённые правила типа «вот такой выкрутас принципиально не сделать безопасным, надо делать иначе»).
  2. Разработчики правы в том, что реализовывать в cryptsetup придумываемые на ходу разношёрстными анонимами схемы (и у каждого своя схема) нет смысла. Естественно, они правы и в том, что KISS до определённого предела рулит.
  3. Между разработчиками нет единого мнения. Один относится более лояльно к нововведениям и более готов к обсуждениям, а другой отрицает всё и сразу, считая понятие отрицаемости заведомым бредом.
  4. Один из итогов дискуссии — то, что отрицаемость вида TC (и даже лучшую) можно получить с помощью костылей в уже существующем cryptsetup. С этим не поспоришь, но возникает политический вопрос: кто кому должен уступить. Или пусть продвинутые пользователи городят костыли в пользу KISS, или пусть разрабы соберутся и-таки упростят им жизнь, добавив стандартные интерфейсы. В потоке бреда разумное предложение по поводу стандартых интерфейсов было только одно — от 23-го апреля этого года, поэтому не удивлён скептицизму разработчиков. Что характерно, на то сообщение не последовало ни одного ответа.
  5. Большая часть высказываемой критики касалось отрицаемости в смысле TC. Эта критика, конечно, была справедливой, и народ правильно подметил слабые стороны такой отрицаемости.

Теперь по поводу предложения: в принципе, идея интересная, и сводится, как я понял, примерно к следующему. Когда мы создаём LUKS, мы задаём не только пассфразу, но и процент от объёма, который мы хотим использовать. Из этих двух параметров выводится информация об аллоцированных блоках под раздел. Её можно писать в хидере в шифрованном виде. Извлечь её можно только по пассфразе. И таких скрытых разделов может быть много, доступ к каждому из которых открывает своя пассфраза (естественно, чтобы создать новый раздел так, чтобы не испортить существующие, нужно дать пассфразы на все ранее созданные разделы). Каждый раздел можно проассоциировать со своим слотом, и проверить, используется ли слот, можно будет только зная правильную пассфразу к нему. Если слот не используется, то никакая пассфраза не будет валидной. Т.е. вместо того, чтобы, как TC, делать обманные разделы и скрытые, автор предложил, в некотором смысле, сделать все разделы скрытыми по умолчанию. Чтобы открыть нужный скрытый раздел, нужно будет указать номер слота и пассфразу. Без этих двух параметров не будет известно ничего: используется ли слот, сколько в нём места и т.д.

Казалось бы, то, что предлагает автор, уже и так можно сделать с помощью LVM, но это неправда. С LVM возникают все те же проблемы, какие были при попытках использовать обычные дисковые разделы вместо dmsetup:
  1. Если раздел создан, но якобы не используется, то это подозрительно.
  2. Если раздел создан, а потом удалён, то как с ним работать? Не повиснет ли система? Где хранить заголовок LVM, содержащий информацию об этом дополнительном разделе? Можно ли дать гарантию, что встроенные средства LVM не перемещают extent'ы, не пишут ничего в выделенное свободное место?
Т.е. не вижу, как это сделать без низкоуровневого функционала dmsetup.

Наконец, уже обсуждавшаяся выше политика: а надо ли вообще что-то делать? Должно ли существование механизмов отрицаемости тоже быть отрицаемым? Если в LUKS официально добавят даже хороший функционал типа вышеописанного, он перекочует во всевозможные инструкции; каждая собака будет знать, что в LUKS есть отрицаемость, а каждого, кто использует LUKS, надо подозревать в использовании этих разрекламированных фич. И совсем другое дело — когда создание отрицаемости требует городить костыли, нет единых стандартных решений, и потому кажется логичным, что без особых на то оснований подозревать случайно попавшегося LUKS-юзера в использовании отрицаемости не будут. Всё-таки одно дело — вести стандартные параметры в командную строку, и другое дело — нагородить кучу костылей и подпорок, иметь для этого нужную мотивацию и квалификацию. Интуитивно мне кажется, что юридически обосновать, что юзер целенаправленно произвёл сотни непростых манипуляций с диском, ОСями и настройками, чтобы получить определённый вид отрицаемости, сложнее, чем обосновать возможность использования стандартной фичи, задаваемой парой опций в командной строке. Это ставит вопрос, нужна ли нам отрицаемость в LUKS вообще. Может, по старинке оно и лучше?

Unknown, теперь ваш ход.
— Гость (24/11/2013 03:57)   <#>
P.S. Спасибо SATtva'е за пофикс лимитов на размеры постов. До последнего не знал, перекорёжит ли пост из-за размера или нет.
— SATtva (24/11/2013 10:27)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Спасибо SATtva'е за пофикс лимитов на размеры постов.
Ничего такого я не фиксил, всё должно быть по-старому. Разве что движок обрёл самоосознание и начал себя апгрейдить. :) А пост, конечно, эпичен.
— unknown (24/11/2013 14:35, исправлен 24/11/2013 14:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Сил разбирать ваш пост нет. Для начала пара общих соображений, чтобы не было недопонимания.


  1. Заведите отдельный документ, наподобие такого, тема уже давно до этого разрослась. Там подробно изложите идею и пошаговые примеры.
  2. Не факт, что выполнив п.1 вы получите какой-то содержательный отклик. Как во всяких некоммерческих разработках, если кому-то что не нравится, он может отказаться от участия в разработке без аргументации. Просто считает неинтересным, громоздким, некрасивым и пр. Даже торпроджект, сидящий на финансировании, может заворачивать предложения от спонсоров, если они ему неинтересны. Подозреваю, что у авторов cryptsetup также ко многим вещам интереса нет.

Теперь чуть подробнее, но всё равно в общем. Я набираю массу команд и вроде сложных и пр. И вроде редко что-то путаю или порчу, но уверен, что скрытый контейнер при ручном костылестроении с требованием скрытности запорю обязательно. Оффсет перепутаю, не тот раздел открою и т.д. И чисто эстетически считаю, что схема должна быть обоснованной и из коробки или никакой. Ещё раз — да, мне хочется что-то нехорошое по аналогии сказать в адрес разрабов Tor'а. за то что TBB по умолчанию настроен не на системный Tor. И несмотря на то, что с отвязкой вроде как разобрались и поправить надо каждый раз всего пару строчек и опций, но каждое обновление TBB — это выбешивающий гемор вместо дежурного update/upgrade или конфигов вида «один раз настроил и всё работает». Здесь чем-то похоже.


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


Вот вы смеётесь над HISTIGNORE — типа полные штаны следов. А мне может просто пофиг, а на самом деле, всё даже естественнее. Возможно, у вас в голове не укладывается мысль, что не все столь аккуратны как вы. У меня в HISTIGNORE честно забит cryptsetup и все потенциально опасные команды. После того как по ошибке забил в строке вместо имени раздела пароль к нему. Станет больше нужно удобства, то впервую очередь скорее ещё придёться жертвовать отрицаемостью. С другой стороны — у меня такое вот объяснение наличия cryptsetup в HISTIGNORE, я его даже не придумывал специально ни для какой отрицаемости, оно само так сложилось.


Над свободным местом вам там было очень весело. А я часто забиваю весь физический том рэндомом, а внутри создаю логические с запасом на вырост и оставляю кучу свободного места. Потому что расширение томов с ФС менее глючно, чем сжатие.


Со сценариями использования свопа и гибернейта у меня свои замороки — он в трёх разных состояния бывает в зависимости от того, как использовался гибернейт: и через /dev/urandom инициализируется, и через keyscript_derived, и может быть с поменянным ключом, который туда пишется рэндомом для затирания и при всём желании мне будет потом нечего выдать для расшифровки.


Это только то, что я ещё могу вспомнить.


Ну т.е. кто активно использует шифрование и экспериментирует с этим, не скрывая сам факт этого, у него и так появится достаточно поводов для отрицаемости. У меня валяются какие-то винты или флэшки, я даже не могу вспомнить ни под каким давлением: я там реально что-то когда-то шифровал или просто забивал рэндомом для каких-то экспериментов и забросил.


При пересечении границы с таможней это может не сработать, да там ничего доказывать не надо, слабообоснованных подозрений достаточно, чтобы просто развернули. Типа: отказ во въезде негражданам — это же не наказание, пускаем только кого хотим, как в гости.


Отрицаемость мне была бы интересна, если бы действительно был разработан какой-то протокол из коробки. Например, в будущем исчезнут все диски HDD, будут только SSD или ещё какие с произвольным доступом. Так чтобы можно было задать функцию: раскидывать шифртекст псевдослучайным образом по всему объёму диска без потери производительности, а при коллизии блоков разных контейнеров, они бы разносились по другим адресам, но чтобы без знания пароля всё выглядело как некое непрозрачное облако с данными. Из которого знание одного из паролей вытягивает часть информации, но расположение секторов ничего не говорит о наличии других разделов. Т.е. когда будет какой-то качественный скачок в технологиях может оно и появится. А сейчас неохота ни городить костыли, ни требовать от разработчиков LUKS ломать и усложнять свой стандарт ради подобного рода фич.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3