Невидимая шифрование уровня PGP на флешке
Здравствуйте!
Подскажите, пожалуйста, PGP-продукт или нечто схожее из криптопрограмм, отвечающее таким характеристикам:
1. Чтобы уже установленная программа не была видна (для органов). То есть они не должны знать сам факт
использования шифрования.
2. Чтобы программа могла работать на флешке автономно (я на ней планирую хранить информацию).
3. Создавала бы на флешке невидимый, замаскированный криптодиск, который нельзя было бы найти.
4. (мб бред) программа находилась бы внутри самого криптоконтейнера.
Спасибо.
комментариев: 11558 документов: 1036 редакций: 4118
*я не знаю на каком глобусе вы живёте, я помню в мои года как какую-то команту в общежитии накрыли за якобы химлабораторию по производству амфетаминов, и насколько я знаю деканат содействовал студентам как только мог, в итоге все обвинения были сняты; не надо в шарагх учиться — вот это да.
Вам уже сказали, не верите – Ваше дело, если не повезет – будет время пересмотреть взгляды.
Это не мешает например сказать матери что по их информации ее сын наркоман и болен спидом, затаскать ее по допросам, провести два обыска в квартире (искали оружие, наркотики и черти что еще) и почти довести до инфаркта. Конечно мать в компьютерных технологиях не бум-бум, но поневоле задумаешся – стоит ли молчание инфаркта у матери?
Ни по какому, просто придет и потребует. Отчислить врядли отчислят, но в деканат на неприятную беседу вызовут, это особенно касается бесплатников.
У начальства своих проблем хватает чтобы еще с ментами за тебя цапаться. Тут 50/50 уволят или нет. Если уволят, то устроиться на новую работу пока следователь ходит за тобой по пятам и все поганит будет трудно.
Кстати, Linux'у можно предъявить "устройство" из маленьких кусочков, которые вообще в разных местах хранятся (и на разных файловых системиах) — он его прозрачно склеит (это штатаная фича dmsetup). Это может использоваться для создания криптотомов не то что без сигнатур, но даже без соли. Последнюю можно хранить отдельно, т.к. она в хидере (хедер LUKS-а вполне успешно отрезается и приклеивается, при отрезании хедера от luks0-криптотома уходит также зашифрованный master key). Что же касается всей схемы защиты в целом, то тут чем больше самодеятельности (в пределах разумного), тем лучше, чтоб не повторяться, ну и трепаться обо всей схеме в целом незачем. На выходе имеется что-то типа
- Флэшки с какими-то файлами и "битым" архивом/видеофайлом, откуда с помощью dd извлекается набор байтов, к которым потом запиливается magic, и которые потом расшифровываются командой openssl.
- dm
- LUKS бэкэндом.
Post scriptum: sapienti sat. Возможно, позже будет инструкция с PoC.© man zshall
А какой командой читать/переписывать фрагменты двоичных файлов/разделов?
Она хоть и критикуется, но не всё так просто. См. комментарии к топику Безопасность через неясность. В частности, там указано что как бы говорит о том, что при переходе от чистой криптографии к стеганографии или ИБ в целом максима Кирхгофа становится лишь недостижимым ориентиром несмотря на то, что в криптографии она — необходимое условие.
Пример с OpenSSL выше уже был приведён (/comment39520), для остальных случаев делается аналогично. Важно то, что некие данные считываются во временный файл (в mfs или tmpfs), а потом там что-то заменяется. Естественно, что для крипторазделов такое не прокатит — нельзя 30 гигов считать, а потом разместить 30гиговый образ в памяти, в то же время софт должен видеть этот образ со всеми сигнатурами, хотя на диске их быть не должно (т.е. при внезапном отключении питания всё должно выглядеть беcсигнатурно). Вот для решения этой проблемы и применяется dm (device mapper): начальная часть криптотома, содержащая сигнатуры — это один маленький кусок, который будет размещён в оперативной памяти после редактирования соответствующих, считанных при помощи dd, данных. Другой кусок — сам криптотом и т.д. Затем dm склеит их все воедино и представит как единое блочное устройство операционной системе со всеми подобающими сигнатурами. К радости Linux'оидов и unknown'а в частности могу порадовать тем, что dm получает признание и за пределами Linux:
Кстати, старый интерфейс (его и сейчас можно использовать), вообще не писал заголовков: Т.е. LUKS можно не использовать, а задавать сразу master key, написав скрипт, который сам будет выводить нужный key из соли и ключа**.
Это необязательно. Зашифруйте скрипт openssl'ем и поместите его внутрь архивного файла, имеющегося на флэшке. Обратная процедура: dd + magic ему запили + расшифруй openssl'ем.
**Хотя стандартных консольных тулзов для PKBDF2 вроде бы нет, есть примеры реализации на Perl'е, а последний есть, по факту, в любой системе. Так же есть стандартный openssl'ный способ, который хуже.
комментариев: 9796 документов: 488 редакций: 5664
Небольшой off к дню введения полиции в России (цитата уже гуляет по интернетам) :-)
© Н. Носов "Незнайка на Луне". 1965 г. Изд-во "Детская литература".
комментариев: 9796 документов: 488 редакций: 5664
© Н. Носов "Незнайка на Луне". 1965 г. Изд-во "Детская литература".
При смене пароля перешифровывается мастер-ключ в слоте, а не сам диск. Если пароль скомпрометирован, лучше перешифровывать, т.к. противник мог скопировать шифрованный паролем мастер-ключ и узнать его.
Двойное шифрование не добавит производительности, да и стоит ли оно того тут, когда можно и без этого.
Кроме того, трудно убедить себя в том, что предыдущая копия точно и надёжно шреддится с диска... да и как это проконтролировать? Смотреть hexdump'ом?