25.10 // Аудит сборки TrueCrypt 7.1a не выявил расхождения с исходными текстами
Опубликованы результаты результаты сравнения официальной бинарной сборки TrueCrypt 7.1a для Windows и сборки, сформированной собственными силами из исходных текстов. Анализ различий показал, что в официальная бинарная сборка не содержит скрытых функций и тождественна поставляемым исходным текстам. Разница наблюдается только в элементах, связанных со сборочным окружением и используемыми на этапе компиляции опциями.
Исследование показало, что правильный подбор используемых при сборке инструментов, воссоздающий оригинальные условия сборки, позволяет сформировать тождественный исполняемый файл и подтвердить, что в распространяемые производителем бинарные сборки не были внесены скрытые изменения. Таким образом удалось подтвердить отсутствие скрытых модификаций без необходимости выполнения трудоёмких операций по обратному инженерингу исполняемых файлов. В настоящее время, усилия по аудиту проекта TrueCrypt могут сосредоточится на изучении исходных текстов и методов шифрования, .
Кроме того, представителям проекта IsTrueCryptAuditedYet удалось связаться с авторами TrueCrypt, которые приветствовали идею проведения независимого аудита безопасности их продукта. Напомним, что в рамках проекта IsTrueCryptAuditedYet создана инициатива для подтверждения отсутствия в TrueCrypt проблем безопасности и скрытых бэкдоров. Одним из подозрений было отсутствие гарантии, что бинарные сборки, которые составляют основную массу загрузок, не содержат закладок и собраны на основании публично доступного исходного кода без внесения скрытых изменений.
Источник: http://www.opennet.ru/opennews/art.shtml?num=38259
Я предвидел такую реакцию.
Вы это уже предлагали, а я уже соглашался. Пока у меня нет времени на эксперименты и их описание по этой теме, поэтому будет отложено. Цельная инструкция не думаю, что имеет много смысла. Надо просто показать, как делаются конкретные нетипичные элементы, а дальше пусть каждый сам из этих элементов собирает решение под себя, свои цели и задачи.
Это как? Специально со зла что ли?
Во-первых, должны быть бэкапы информации, и она там должна храниться схожим скрытым образом. Во-вторых, оффсет задаёт, какую область диска вы считаете в память и поместите в файл в /tmp на tmpfs (при использовании openssl). Если вы ошиблись с оффсетом, вы просто его не расшифруете либо не сможете продолжить процедуру, т.к. в расшифрованном тексте будет мусор. Т.е. при считывании этих параметров на сам диск ничего не пишется, а когда они считаны, монтирование всё равно будет происходить с помощью автоматических скриптов. Не руками же вы будете вбивать всю БД для dmsetup, в конце концов. Если скрипты правильные и работают, то всё делается близко к автоматическому.
Если openssl не используется (вместо этого применяем plain mode в cryptsetup), то замечение всё равно остаётся в силе: указав неправильный оффсет, вы получите доступ к случайному мусору и не сможете продолжить процедуру. Сам раздел при этом испорчен не будет; просто mount напишет, что файловая система не найдена. Если перемонтируете с правильными данными, всё будет ОК.
Понятие «из коробки» у всех разное. Иные бы вам сказали, что «из коробки» — это когда есть ярлык на рабочем столе, на который шёлкнул, и всё само сделалось, а вбивать команды в терминал — это точно не «из коробки».
Дежурный update/upgrade — это перекладывание всей ответственности на того, кто эти скрипты пишет. Даже если всё настроено правильно, перед запуском всё равно положено проверять каждую подсистему и убеждаться, что она работает, как положено.
Strong security/anonymity — это как запуск ракеты. И чего там космические инженера вокруг неё сутками выплясывают перед пуском? Давно пора всё сделать удобным: привезли, подняли, запустили. Всё на всё — пол часа максимум. И космонавтов пусть по пол года в Звёздном Городке не держат перед полётом, накладно это. Надо так: вчера купил билет на МКС, а сёгодня уже полетел.
Есть плата удобством, а также расходом времени. Я не могу, например, как вы или многие другие, в любой момент закрыть крышку ноутбука и положить его в сумку, зная, что все системы останова отработают правильно. Также я не могу открыть крышку, ввести один пароль, и сразу
стать рутомполучить доступ к нужной рабочей среде. Да, это неудобно, но я понимаю, что иначе не сделать. Удобство и безопасность обычно ортогональны друг другу.HISTIGNORE — это действительно смешно, потому что первая же ассоциация — это
Если это был файл на /tmp, который на tmpfs, то достаточно его стереть, он на диск не пишется, да и вообще чего так сильно бояться, если шифрование полнодисковое? В случае обострённой паранои можно перезагрузить систему.
У меня тоже случаются ошибки. Какой-то раз стёр файл, к которому не было копий. Файл не очень важный, но всё равно неприятно. Другой раз /tmp стёр целиком, пришлось пересоздавать и назначать ему правильные права. Впрочем, ничего из перечисленного не было фатальным.
Прийдётся или не прийдётся — это вопрос о моделях угрозы. У каждого они свои, и один другого не поймёт. Если у кого-то риски и ставки высоки, он может предпочесть вообще приостановить деятельность до тех пор, пока не появится возможность снова гарантировать безопасность.
Значит, всё-таки используете отрицаемое шифрование вольно или невольно. Пусть шифруете нули, пусть случайным паролем, но всё равно шифруете отрицаемо. :-)
Вы не рассказывали детали о том, как скрывать что-то в свопе, но даже из общих соображений возникает ограничение на объём. Не будете же вы сто гигабайт отводить под своп? Иначе это вызовет подозрение.
Когда я обрисовывал схему, предполагалось, что она должна давать, в том числе, отрицание шифрования (по аналогии со стеганографией). Если кому-то достаточно отрицаемого шифрования (не путать с отрицанием шифрования), то никто не запрещает применять эту же схему поверх шифрованного блочного устройства.
Насчёт «достаточно поводов» — не знаю, я бы не торопился с такими выводами. Конечно, если у вас склад с сотней дисков, а на некоторых пыль уже годами не смахивалась, то вам могут поверить, но в более реалистичных случаях — сомневаюсь. По крайней мере, отрицаемое шифрование тут хуже точно не сделает.
А я не о том же ли? Вот это предложение в рассылке
именно то и хочет сделать. Я его пытался передать своими словами, но, может, не очень удачно получилось. Автор сообщения тоже не стал его полностью формализовывать, но его мысли понятны. Авторы cryptsetup на это ничего не ответили.
Я поначалу тоже думал о случайном расположении блоков, но потом понял, что оно ненужно. Если у вас и так все разделы скрытые, не надо отрицать использование шифрования, то зачем блоки по всему диску раскидывать? Достаточно отрезать место на разделы попорядку и делать для него шифрованные хидеры. Зная пароль, вы определите что он правильный, а также границы раздела. Это вам ничего не скажет о других разделах на этом же диске (есть они в принципе в наличии или там просто свободное место). Поскольку раскидывать блоки будет не надо, производительность LUKS не упадёт, и никакого «качественного скачка в технологиях» не требуется. Требуется только добротная формализация и политическая воля на включение этого в стандарт. Ну, это если вообще считать, что эта фича в LUKS нужна, в чём я не уверен:
Во времена, когда Eridan всё валил в один топик, его корёжило, поэтому приходилось разбивать на подстраницы, и это при том, что его топик вроде не был таким уж большим.
комментариев: 9796 документов: 488 редакций: 5664
Проблема в том, что это делает новый LUKS несовместимым с текущим. Нужны будут слоты дополнительного размера. И прежде, чем делать такую схему принудительной для всех по умолчанию, её возможно сделали бы добровольно включаемой, пока она не стабилизировалась.
Правильнее сказать, что для решения проблемы совместимости понадобятся дополнительные слоты, причём в одних будет старый LUKS-заголовок, а в других новый, как-то так.
Теоретики же разрабатывают PFS. Пусть это непрактично и далеко от реальности, но хоть какая-то движуха есть. А есть ли формализованные теоретические наработки по отрицаемому шифрованию? Хотя если даже режимы дискового шифрования толком не проработаны, то да, о чём это я...
комментариев: 9796 документов: 488 редакций: 5664
В новых версиях LUKS обещали попробовать внедрить новые режимы Wide Block Encryption CMC и EME, если их поддержка появится в cryptoAPI ядра.
Не факт, что что-то будет ввиду новостей типа написанных по вашей же ссылке:
И вообще:
комментариев: 9796 документов: 488 редакций: 5664
Да, это известный факт. Обычно, в работах не стесняются даже намеренно шутливых или провокационных названий, но для стандарта оставить такое название постеснялись.
комментариев: 9796 документов: 488 редакций: 5664
Вот очередной, к счастью малоизвестный (XCB) режим дискового шифрования вроде как теоретически поломали. Так что дисковое шифрование — не такая простая вещь, как кажется.
[/offtop]
а также матерных [сайт требует JS]:
Есть какая-то глубокая в этом связь, химическая связь...
Раньше уже обращал на это внимание, а в этой работе оно повторно встретилось — мешанина шрифтов для именных объектов в формулах типа msb, pad, Adv, Perm, lbit и др. Есть какая-то конвенция, что писать простым шрифтом (\mathrm{NAME}), а что ещё и со сменой шрифта (я так понимаю, \mathrm{\textsf{NAME}})?
Критика отрицаемости в TrueCrypt в терминах теории игр.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Это касается не только TrueCrypt, а вообще всего:
© Bruce Schneier, Tor User Identified by FBI.
А тем временем, очередному обвиняемому в терроризме в Англии добавили срок за забытый пароль от шифрованной флэшки. Подробнее здесь.
Т.е. срок 4 месяца добавили уже после раскрытия пароля. Если бы не использовал такой же пароль, как и на других устройствах (что помогло его раскрыть), то могли бы и больше добавить.
В приведённой цитате вообще-то написано не об этом. Это так, как вы пишете, только если оба игрока выбирают доминантную стратегию. Доминантная стратегия для бандитского криптоанализа — "пытаем до смерти, и нам за это ничего не будет". Нет никаких издержек и рисков. Извините, но даже Гуантанамо и секретные тюрьмы ЦРУ не укладываются в эту модель на все сто: надо будет оправдываться перед обществом, если вскроется (а оно вскрылось, вы знаете), объяснять смерть людей, их исчезновение. А модель реальных бандитов (хоть в погонах, хоть без) чаще всего столь далека от ЦРУ, что говорить о полностью доминантной стратегии вообще бессмысленно.
Когда вы начнёте приближать модель к реальности, вам придётся ввести в игру третий (или четвёртый, пятый и т.д.) параметр, а выигрыш будет определяться не суммой баллов по всем параметрам, а какой-то хитрой функцией от них.
Английское законодательство этому тоже не пример. Если раскрытие информации приведёт к тому, что вас посадят пожизненно, то лучше отсидеть положенные 5 лет. Если раскрытие информации приведёт к тому, что помимо вас будут убиты другие люди, а не только вы сядете навечно, то лучше сесть навечно, ничего не раскрывая. Я слышал в народе предложение так адаптировать английский закон о раскрытии ключей, чтоб за нераскрытие светило ровно столько, сколько вам дадут, если докажут то, в чем вас подозревают. Но даже такой усиленный закон не делает раскрытие пароля осмысленным, потому что наказание за одно и то же может отличаться на порядок, если известны детали, а детали зашифрованы и противнику неизвестны, не говоря уже о том, что подозревать вас могут в одном, а получив доступ, докажут ещё и то, в чём даже не подозревали.
Хорошо сделал, что раскрыл? Скостил себе срок до 4 месяцев? Вы это хотите сказать? Здесь он себе скостил, а в другом месте набавил по полной:
Если не опускаться до журнализма и правильно расставлять акценты, обратите внимание, за что он уже отсидел:
Вы здесь чего-нибудь про пароли видите? Я тоже нет.
В сухом остатке имеем:
- Мусульманин.
- Мусульманское имя.
- Доказано планирование участия в теракте.
- Полученный срок слабо связан с невыдачей пароля. Он бы сел, даже если у него компьютера не было вообще.
- Новый большой срок (уже не 4 месяца) он получит за то, что раскрыл пароль, а не за то, что скрыл его.
Там за одно и то же нельзя судить дважды, так? Тогда отсидел бы свой пятак и был бы свободен. Зачем его дёрнуло раскрывать пароль — неясно. Даже если там можно судить дважды, и судили за то же самое, увеличив срок, то лучше сидеть только за нераскрытие пароля, чем за то, что он скрывал.В любом случае, история очень далека от "взяли случайного параноика, нашли у него шифрованный раздел и посадили 'ни за что, ни про что'". Да, такое тоже могло бы быть, но конкретно данный случай явно не из этого числа.
Судя по методу выбора пароля, он явно не гик. Наверняка поди использовал стандартый софт, не скрывающий то, что это шифрованный том, хотя мог бы подумать, как запрятать данные так, чтобы доказать их наличие в суде было бы проблематично. Если бы там было хотя бы бессигнатурное шифрование неразмеченного дискового пространства, это уже было бы лучше; наверняка в таком случае история с паролем вообще бы не фигурировала в деле.
комментариев: 9796 документов: 488 редакций: 5664
Так вот, срок там светит якобы только в том случае, если у следствия/суда есть обоснованные подозрения, что обвиняемый действительно помнит пароль, но делает вид, что не помнит. Например, экспертиза показывает, что после освобождения обвиняемый повторно пользовался этими же зашифрованными данными.
В случае с этим Хуссейном, он пароль якобы забыл, но уже после этого заявления якобы использовал такой же пароль в деле о мошенничестве. Так что добавили ему возможно на основании того, что были доказательства, что он первый раз солгал на суде или следствии. Факт невыдачи пароля надо доказать, как умышленное причинение препятствий следствию/суду, так что с этим законом возможно тоже не всё так просто.
Другое дело, что даже английский суд может пришить такие нечёткие доказательства белыми нитками. Официально признанные случаи судебного/полицейского произвола в Англии вроде как известны.