id: Гость   вход   регистрация
текущее время 07:14 20/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 След.
Комментарии [скрыть комментарии/форму]
— Гость (24/11/2013 17:28)   <#>

Я предвидел такую реакцию.


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


Это как? Специально со зла что ли?


Во-первых, должны быть бэкапы информации, и она там должна храниться схожим скрытым образом. Во-вторых, оффсет задаёт, какую область диска вы считаете в память и поместите в файл в /tmp на tmpfs (при использовании openssl). Если вы ошиблись с оффсетом, вы просто его не расшифруете либо не сможете продолжить процедуру, т.к. в расшифрованном тексте будет мусор. Т.е. при считывании этих параметров на сам диск ничего не пишется, а когда они считаны, монтирование всё равно будет происходить с помощью автоматических скриптов. Не руками же вы будете вбивать всю БД для dmsetup, в конце концов. Если скрипты правильные и работают, то всё делается близко к автоматическому.

Если openssl не используется (вместо этого применяем plain mode в cryptsetup), то замечение всё равно остаётся в силе: указав неправильный оффсет, вы получите доступ к случайному мусору и не сможете продолжить процедуру. Сам раздел при этом испорчен не будет; просто mount напишет, что файловая система не найдена. Если перемонтируете с правильными данными, всё будет ОК.


Понятие «из коробки» у всех разное. Иные бы вам сказали, что «из коробки» — это когда есть ярлык на рабочем столе, на который шёлкнул, и всё само сделалось, а вбивать команды в терминал — это точно не «из коробки».


Дежурный update/upgrade — это перекладывание всей ответственности на того, кто эти скрипты пишет. Даже если всё настроено правильно, перед запуском всё равно положено проверять каждую подсистему и убеждаться, что она работает, как положено.

Strong security/anonymity — это как запуск ракеты. И чего там космические инженера вокруг неё сутками выплясывают перед пуском? Давно пора всё сделать удобным: привезли, подняли, запустили. Всё на всё — пол часа максимум. И космонавтов пусть по пол года в Звёздном Городке не держат перед полётом, накладно это. Надо так: вчера купил билет на МКС, а сёгодня уже полетел.


Есть плата удобством, а также расходом времени. Я не могу, например, как вы или многие другие, в любой момент закрыть крышку ноутбука и положить его в сумку, зная, что все системы останова отработают правильно. Также я не могу открыть крышку, ввести один пароль, и сразу стать рутом получить доступ к нужной рабочей среде. Да, это неудобно, но я понимаю, что иначе не сделать. Удобство и безопасность обычно ортогональны друг другу.


HISTIGNORE — это действительно смешно, потому что первая же ассоциация — это
$ export HISTIGNORE="*pron*"
Т.е. кто-то перечисляет в этой опции всё то, что он хотел бы скрыть, а по факту получается, что предоставляет противнику полный список скрываемого.


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

У меня тоже случаются ошибки. Какой-то раз стёр файл, к которому не было копий. Файл не очень важный, но всё равно неприятно. Другой раз /tmp стёр целиком, пришлось пересоздавать и назначать ему правильные права. Впрочем, ничего из перечисленного не было фатальным.


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


Значит, всё-таки используете отрицаемое шифрование вольно или невольно. Пусть шифруете нули, пусть случайным паролем, но всё равно шифруете отрицаемо. :-)


Вы не рассказывали детали о том, как скрывать что-то в свопе, но даже из общих соображений возникает ограничение на объём. Не будете же вы сто гигабайт отводить под своп? Иначе это вызовет подозрение.


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

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


А я не о том же ли? Вот это предложение в рассылке

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

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

Я поначалу тоже думал о случайном расположении блоков, но потом понял, что оно ненужно. Если у вас и так все разделы скрытые, не надо отрицать использование шифрования, то зачем блоки по всему диску раскидывать? Достаточно отрезать место на разделы попорядку и делать для него шифрованные хидеры. Зная пароль, вы определите что он правильный, а также границы раздела. Это вам ничего не скажет о других разделах на этом же диске (есть они в принципе в наличии или там просто свободное место). Поскольку раскидывать блоки будет не надо, производительность LUKS не упадёт, и никакого «качественного скачка в технологиях» не требуется. Требуется только добротная формализация и политическая воля на включение этого в стандарт. Ну, это если вообще считать, что эта фича в LUKS нужна, в чём я не уверен:

Это ставит вопрос, нужна ли нам отрицаемость в LUKS вообще. Может, по старинке оно и лучше?


Во времена, когда Eridan всё валил в один топик, его корёжило, поэтому приходилось разбивать на подстраницы, и это при том, что его топик вроде не был таким уж большим.
— unknown (24/11/2013 19:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Это предложение в рассылке возможно хорошее, по крайней мере я согласен, что на первый взгляд оно выглядит лучше всего предложенного.

Проблема в том, что это делает новый LUKS несовместимым с текущим. Нужны будут слоты дополнительного размера. И прежде, чем делать такую схему принудительной для всех по умолчанию, её возможно сделали бы добровольно включаемой, пока она не стабилизировалась.
— Гость (24/11/2013 19:49)   <#>

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

Теоретики же разрабатывают PFS. Пусть это непрактично и далеко от реальности, но хоть какая-то движуха есть. А есть ли формализованные теоретические наработки по отрицаемому шифрованию? Хотя если даже режимы дискового шифрования толком не проработаны, то да, о чём это я...
— unknown (24/11/2013 20:21, исправлен 24/11/2013 20:23)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

В новых версиях LUKS обещали попробовать внедрить новые режимы Wide Block Encryption CMC и EME, если их поддержка появится в cryptoAPI ядра.

— Гость (28/11/2013 23:38)   <#>

Не факт, что что-то будет ввиду новостей типа написанных по вашей же ссылке:

CMC and EME were considered for standardization by SISWG. CMC was rejected for technical considerations. EME is patented, and so is not favored to be a primary supported mode.

И вообще:
the proper name should be XTC (XEX TCB CTS), but that is already used to denote the ecstasy drug
— Гость (08/12/2013 00:00)   <#>
Как там аудит? Новости есть?
— unknown (08/12/2013 22:40)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Да, это известный факт. Обычно, в работах не стесняются даже намеренно шутливых или провокационных названий, но для стандарта оставить такое название постеснялись.
— unknown (09/12/2013 12:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
[offtop]
Вот очередной, к счастью малоизвестный (XCB) режим дискового шифрования вроде как теоретически поломали. Так что дисковое шифрование — не такая простая вещь, как кажется.
[/offtop]
— Гость (12/12/2013 02:14)   <#>

а также матерных [сайт требует JS]:

In the present work, the multivariate kinetic complexation of a new synthesized ligand, 1-(2″-hydroxyl cyclohexyl)-3′-[aminopropyl]-4-[3′-aminopropyl]piperazine (Pizda) and Cu2+ in 50% ethanol–water solution is investigated using the UV–vis stopped-flow technique and state-of-the-art multi-wavelength numerical analysis.

ethanol–water

(Pizda)

Есть какая-то глубокая в этом связь, химическая связь...


Раньше уже обращал на это внимание, а в этой работе оно повторно встретилось — мешанина шрифтов для именных объектов в формулах типа msb, pad, Adv, Perm, lbit и др. Есть какая-то конвенция, что писать простым шрифтом (\mathrm{NAME}), а что ещё и со сменой шрифта (я так понимаю, \mathrm{\textsf{NAME}})?
— Гость (16/01/2014 21:46)   <#>
When analyzed with game theory, it turns out that TrueCrypt's plausible deniability feature, which lets you hide a second encrypted volume inside the "outer" or normal volume, is useless.

Okay, that's a bit of an exaggeration, but let me explain.

Consider the following situation: You are a dissident under an oppressive government, and you want to encrypt your plans to overthrow the government. You are pretty sure that you will eventually get caught and your government will force you, by torture, to disclose your password. Suppose you decide to use TrueCrypt, and you're wondering whether or not to have a hidden volume.

if you and the government are both rational and self-interested, then you are going to use a hidden volume, and the government is going to keep torturing you.

So, at least in this situation (which arguably is why the feature exists), TrueCrypt's plausible deniability doesn't give dissidents any advantage. In fact, it could make things worse for the dissident if they don't know about the feature and end up being tortured for a password that doesn't even exist.

In other scenarios the feature can be useful. If the attacker has limited resources (i.e. can only torture you for 30 minutes), or if you are "innocent until proven guilty" under the law, then it can be advantageous to use a hidden volume. Just don't recommend TrueCrypt to your friends in North Korea, or at least make sure they use a hidden volume.

Критика отрицаемости в TrueCrypt в терминах теории игр.
— SATtva (17/01/2014 07:35)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Что, в общем-то, не новость, в топиках по TC у нас звучали те же рекомендации: если в модель угрозы входит бандитский криптоанализ (или английское законодательство), то фича скорее усугубит ситуацию для пользователя.
— unknown (17/01/2014 10:24, исправлен 17/01/2014 10:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Это касается не только TrueCrypt, а вообще всего:


This is one of the problems of using a rare security tool. The very thing that gives you plausible deniability also makes you the most likely suspect. The FBI didn't have to break Tor; they just used conventional police mechanisms to get Kim to confess.
Tor didn't break; Kim did.

© Bruce Schneier, Tor User Identified by FBI.


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


after police told Hussein's lawyers they had launched a fresh investigation into alleged credit card fraud by Hussain late last year, his memory suddenly improved.

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

— Гость (18/01/2014 01:06)   <#>

В приведённой цитате вообще-то написано не об этом. Это так, как вы пишете, только если оба игрока выбирают доминантную стратегию. Доминантная стратегия для бандитского криптоанализа — "пытаем до смерти, и нам за это ничего не будет". Нет никаких издержек и рисков. Извините, но даже Гуантанамо и секретные тюрьмы ЦРУ не укладываются в эту модель на все сто: надо будет оправдываться перед обществом, если вскроется (а оно вскрылось, вы знаете), объяснять смерть людей, их исчезновение. А модель реальных бандитов (хоть в погонах, хоть без) чаще всего столь далека от ЦРУ, что говорить о полностью доминантной стратегии вообще бессмысленно.

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

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


Хорошо сделал, что раскрыл? Скостил себе срок до 4 месяцев? Вы это хотите сказать? Здесь он себе скостил, а в другом месте набавил по полной:

At this point the police were able to access the memory stick, discovering it contained evidence useful for their inquiry into the alleged financial fraud rather than anything directly related to terrorism or national security.

Если не опускаться до журнализма и правильно расставлять акценты, обратите внимание, за что он уже отсидел:

Hussain was jailed for five years and three months last April for the far more serious offence of conspiring to take part in a planned attack on a Territorial Army base in Luton. Along with three other men, Hussain pleaded guilty to plotting to use a remote-control toy car to plant a homemade bomb at the TA centre. The suspects were arrested before any preparations for an attack were put together.

Вы здесь чего-нибудь про пароли видите? Я тоже нет.

В сухом остатке имеем:
  1. Мусульманин.
  2. Мусульманское имя.
  3. Доказано планирование участия в теракте.
  4. Полученный срок слабо связан с невыдачей пароля. Он бы сел, даже если у него компьютера не было вообще.
  5. Новый большой срок (уже не 4 месяца) он получит за то, что раскрыл пароль, а не за то, что скрыл его.
Там за одно и то же нельзя судить дважды, так? Тогда отсидел бы свой пятак и был бы свободен. Зачем его дёрнуло раскрывать пароль — неясно. Даже если там можно судить дважды, и судили за то же самое, увеличив срок, то лучше сидеть только за нераскрытие пароля, чем за то, что он скрывал.

В любом случае, история очень далека от "взяли случайного параноика, нашли у него шифрованный раздел и посадили 'ни за что, ни про что'". Да, такое тоже могло бы быть, но конкретно данный случай явно не из этого числа.

Судя по методу выбора пароля, он явно не гик. Наверняка поди использовал стандартый софт, не скрывающий то, что это шифрованный том, хотя мог бы подумать, как запрятать данные так, чтобы доказать их наличие в суде было бы проблематично. Если бы там было хотя бы бессигнатурное шифрование неразмеченного дискового пространства, это уже было бы лучше; наверняка в таком случае история с паролем вообще бы не фигурировала в деле.
— unknown (18/01/2014 19:30)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Были какие-то толкования на счёт английского законодательства, но ссылки потерял и не уверен даже, что правильно понял.

Так вот, срок там светит якобы только в том случае, если у следствия/суда есть обоснованные подозрения, что обвиняемый действительно помнит пароль, но делает вид, что не помнит. Например, экспертиза показывает, что после освобождения обвиняемый повторно пользовался этими же зашифрованными данными.

В случае с этим Хуссейном, он пароль якобы забыл, но уже после этого заявления якобы использовал такой же пароль в деле о мошенничестве. Так что добавили ему возможно на основании того, что были доказательства, что он первый раз солгал на суде или следствии. Факт невыдачи пароля надо доказать, как умышленное причинение препятствий следствию/суду, так что с этим законом возможно тоже не всё так просто.

Другое дело, что даже английский суд может пришить такие нечёткие доказательства белыми нитками. Официально признанные случаи судебного/полицейского произвола в Англии вроде как известны.
— Гость (19/01/2014 02:20)   <#>
Такое ваше объяснение звучит разумно. Я тоже не специалист по английскому законодательству.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3