id: Гость   вход   регистрация
текущее время 22:06 28/03/2024
создать
просмотр
редакции
ссылки

Инструкция по отрицаемому хранению данных на носителе с Tails

Цель


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

Общая идея


На носитель устанавливается Tails, а на оставшемся свободном месте диска (в хвосте) делается бессигнатурный шифрованный раздел для хранения данных.

Легенда


Затёрли флэшку/диск/SD-карточку рандомом, потом записали стандартный Tails по инструкции с сайта, и всё на том. Больше ничего не делали, никаких скрытых данных нет.

Подводные камни


  1. В ядре Linux решили не заморачиваться консистентностью разных компонент ядра, просто запретив их взаимодействие. Итог: всё dm-based (dmsetup, cryptsetup, LVM) совместимо между собой, но несовместимо с монтированием файловой системы. В частности, если на диске /dev/sda есть файловая система на /dev/sda<N>, и она подмонтирована, нельзя адресовать свободное (неразбитое) дисковое пространство на /dev/sda с помощью dmsetup или cryptsetup (ядро ставит bd_claim на блочное устройство /dev/sda, запрещая его использование dm'у; задаваемые оффсеты и размеры при этом совершенно неважны). Однако, если файловая система находится на ином блочном устройстве (важен логический, а не физический уровень) — к примеру, на /dev/mapper/name, который зацеплен на /dev/sda<N>, монтирование этой ФС не будет препятствовать использованию dm/cryptsetup на /dev/sda.1

  1. По умолчанию Tails не грузит все файлы в память, а каждый раз запрашивает их с диска/флешки, т.е. файловая система с диска будет всегда подмонтирована. Из-за предыдущего пункта это блокирует возможность использовать неразбитое дисковое пространство для хранения данных. Можно, конечно, загрузить Tails, потом на лету менять MBR, добавляя и убирая нужные разделы, но это геморройно, грязно и может испортить легенду.

Недокументированные возможности


С помощью реверс-инжиниринга можно выяснить, что в Tails есть тайная недокументированная опция загрузки, которая держится в строжайшем секрете — toram («to RAM»). Она позволяет вэйпонизировать Tails в нужном направлении: в самом начале загрузки, когда выводится меню isolinux с двумя вариантами (обычный и fail-safe), выбираем нам нужный, нажимаем tab, дописываем toram к опциям загрузки и грузим. После этого Tails будет загружен в память, а файловые системы на носителе, с которого он был загружен, не будут подмонтированы — носитель можно будет даже отключить, и Tails продолжит работать из RAM.

Семь шагов на пути к успеху


  1. Затираем весь диск/флешку [1], [2].

  1. Следуя инструкциям на сайте Tails, с помощью isohybrid преобразовываем iso в образ, нужный для записи на флешку/диск.2 (Примечание: возможно, в этом уже нет необходимости).

  1. Записываем получившийся образ с помощью команды
    # dd if=/path/to/file.iso of=/dev/sdb
    (предполагаем, что запись идёт на /dev/sdb). Это создаёт на устройстве MBR и таблицу разделов, в первом разделе (/dev/sdb1) будет находиться Tails.

  1. Создаём бессигнатурный шифрованный раздел на неразбитом пространстве диска:3
    # cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -o оффсет create NAME /dev/sdb
    Оффсет (задается в секторах) можно не запоминать, потому что его легко посмотреть fdisk-ом — это последний сектор первого раздела + 1. В данном случае мы используем вариант «выделяем всё пространство до конца диска». Однако, лучше сделать иначе: если размер носителя позволяет, взять какой-то фиксированный offset побольше, чтобы при последующем обновлении Tails и его записи на этот же носитель через dd (размер может увеличиться) наш бессигнатурный раздел не был затёрт.

    Вышеприведённая команда cryptsetup создаёт устройство /dev/mapper/NAME с несменяемым паролем на шифрование. Внутри него лучше создать LVM с LUKS-шифрованными логическими томами или просто один LUKS-раздел на всё устройство, чтобы не терять возможность менять пароль, убивать слоты и т.д. Как это сделать технически — уже обсуждалось [3], [4].

  1. Если работаем c SD-карточки, имеющей физический переключатель для блокировки записи, включаем его: на этапе загрузки запись на носитель нам не понадобится.

  1. Грузимся, включая опцию загрузчика toram (см. выше).

  1. При поставленном локе на адаптере (см. п.5, этот комментарий только на случай, если он используется) и dmsetup и cryptsetup позволяют создавать только read only mappings, причем cryptsetup умный и сам догадывается включить режимр r/o, а вот dmsetup'у надо указывать опцию -r явно. В предположении, что нужный раздел с данными уже заранее создан на свободном дисковом пространстве, монтируется он так же:
    # cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -o оффсет create NAME DEVICE
    (остальные опции подключения LUKS/LVM добавляем по вкусу, если нужны). Если же нужно сделать r/w-доступ к скрытому разделу на SD-карте, надо:

    1. Достать SD-карту (предполагаем, что она не подмонтирована).
    2. Объяснить ядру, что мы её достали (бывают «умные» адаптеры, которые usb disconnect не ловят, пока к SD-карте не обратишься).
    3. Cнять лок и перевставить SD-карточку.
    4. Подключить скрытый раздел и смонтировать его в режиме r/w.

    Потом аналогичным образом можно вернуть носитель в состояние r/o и снова поставить лок (и всё это делается без перезагрузки Tails!). Понятно, что загрузка с r/o-носителя, а также физическое отключение записи на время, когда она ненужна, повышают безопасность (Вдруг Tails будет взломан? Атакующему будет тяжелее поменять загрузочный образ).


1Уже давно пора разделы диска делать принудительно через dm, тогда бы такой проблемы не возникло вообще. Некоторые пояснения:

1) fdisk (а равно dd и т.п. проги) не делают так называемый bd_claim — это обращение к ядру с заявкой на использование, а dmsetup его делает, и именно на этой стадии его обламывают. Судя по всему, авторов Linux заботит консистентность ядра самого с собой, а не ядра и юзерленда.
2) Дело не в том, что раздел открыт на запись; дело в том, что при монтировании ФС ядро делает bd_claim. Таким образом, никакая другая компонента ядра не может сделать bd_claim на подраздел и блочное устройство (диск) в целом (т.е. дело не в том, где физически находится монтируемый подраздел, а в том, логической частью какого блочного устройства он является — bd_claim делается именно на блочное устройство; из-за этого можно без проблем подмонтировать mapping и это ни на что не повлияет — каждый mapping сам по себе блочное устройство).
3) Это проблемы Linux, а точнее — интерференция системы подразделов и системы dm. Во имя консистентности был забит костыль, дабы эти подсистемы не мешали друг другу. В общем, как всегда, проблема legacy и эволюционного проектирования.

Монтирование ФС — это частный случай bd_claim. Важно то, что

a) Никакие две раздельные компоненты ядра не могут одновременно делать bd_claim на блочные устройства и подразделы в них.
b) Одна и та же компонента ядра может это делать без ограничений. Например, всё, что делается через dm (это и dmsetup linear, и dm-crypt, и LVM) совместимо друг с другом.

Т.е. dm внутри себя поддерживает консистентность маппингов, а костыль с bd_claim сделан, чтобы не заморачиваться консистентностью разных подсистем ядра для доступа к одним и тем же блочным устройствам.
2Обычные iso'шки не поддерживают загрузки с флэшек хотя бы потому, что там нет MBR нет и т.п. Гибридные iso когда делаются, а когда нет — это от авторов зависит. Не исключаю, что в Debian iso гибридные по умолчанию.
3Поскольку по умолчанию TRIM отключен, микроконтроллер не знает, какие сектора диска ОС считает свободными. Для нашего случая это хорошо, т.к. неиспользуемое место не будет обнуляться в случае флэшек и SD-карточек.


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии [скрыть комментарии/форму]
— Гость (31/01/2015 16:54)   <#>
Уточню вопрос. Хотелось бы, чтобы легенда позволяла отрицать использование cryptsetup вообще. Чтобы на предложение "покажите, чем затирали диск" можно было ответить "затирал вот этой Смерть-Затиралкой". Чтобы невозможно было доказать, что это не так.
— Гость (31/01/2015 17:12)   <#>

Не знал что у cryptsetup есть почерк.
— Гость (31/01/2015 17:26)   <#>

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

Альтетнативы — затирать через urandom. Можете сказать, что тёр как dd if=/dev/urandom of=/dev/sda, но учтите, что эксперт может быть в курсе того, что скорость urandom довольно низка, и если вы скажете, что, к примеру, диск затёрся за сутки, хотя реально должен был тереться недели две при скорости urandom, это разрушит вашу легенду. Впрочем, вы можете сказать, что использовался не urandom, а Havege + /dev/random — он даёт высокую скорость (команда будет почти та же: dd if=/dev/random of=/dev/sda). Но, опять же, легко может выясниться, что вы никогда им не пользовались и вас словят на незнании технических деталей. Иной вариант — затирали /dev/random'ом, потому что у вас дома есть быстрый QRNG (правдоподобная версия?). Наконец, ещё есть способ с openssl, но openssl — криптотул/криптолиба, так что вдуг она вам тоже покажется «палевом» (и пофиг, что SSL с сайтами как-то должно работать)?

Если что, уясните одну вещь: надежное затирание требует случайных данных, а случайные данные надёжно генерируются только криптотулзами, связанными с тем или иным шифрованием.
— Гость (31/01/2015 17:44)   <#>

Не берусь отверждать, что почерк есть. Но требуется другое: убедительно ответить на вопрос "чем затирали диск?" и при этом не демонстрировать свое знакомство с cryptsetup.

Допустим, можно ответить "затирал с помощью dd if=/dev/urandom of=/dev/sdb". Требуется, чтобы ответ был окончательным и не подлежал сомнению. Чтобы невозможно было по структуре данных доказать, что для затирания было использовано нечто другое.

А еще лучше, чтобы можно было вообще указать на конкретную пользовательскую затиралку, почерк которой было бы невозможно отличить от тех данных, которые имеются в неразбитой части диска.
— Гость (31/01/2015 17:55)   <#>

cryptsetup'ом тоже можно затирать по-разному. Можно тереть только конкретный дисковый раздел, а можно тереть весь диск, что уничтожит, в том числе, всю таблицу разделов на нём. Делают ли так разные GUI'шные затиралки? Есть ли там такие опции? Не знаю.


Это хороший вариант, только протестируйте его скорость сначала, чтобы знать, сколько ушло бы на затиранием таким способом. Строго говоря, urandom — даже лучший ГПСЧ, чем пошифрованные нули при затирании cryptsetup'ом (хотя отличить на уровне возможностей сегодняшнего криптоанализа всё равно невозможно).


Не хочется демонстрировать своё знакомство с dd? Или вообще с Linux? Так далеко можно пойти, но, по-моему, это малоконструктивно.
— Гость (31/01/2015 18:53)   <#>
Вы извините, пожалуйста, но я пишу медленно, поэтому может показаться, что реагирую невпопад или повторяю вопрос, когда уже получил ответ.



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

Если



то вопрос решен.

Есть ли какие исследования по способам статистической дифференциации данных разных крипто-утилит или ГПСЧ?
— Гость (31/01/2015 20:53)   <#>

На системный ГПСЧ (PRNG) налагаются дополнительные требования, которые для гаммы, используемой для затирания диска, несущественны. В любом случае, практическая дифференциация невозможна (в противном случае это было бы серьёзной уязвимостью AES). Подробнее упоминалось в комментах [1], [2]. /dev/urandom — это именно ГПСЧ (PRNG).
— Гость (31/01/2015 22:04)   <#>
Спасибо всем за ответы.
— unknown (31/01/2015 22:18, исправлен 31/01/2015 22:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Так может не получиться, если сливать данные из /dev/random блоками, то будет неполный блок после первых же 4Mb и вылет с ошибкой, хотя при проверке в /dev/null всё работает. Нужен какой-то флаг для dd — или noerror, или notrunc. Наконец, даже блоками — медленнее, чем /dev/urandom, там почти такой же алгоритм, как в нём, да ещё и тратится время на подкачку с havege. С havege надо напрямую, чтобы быстро: haveged -n 0 | dd of=/dev/sda



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

— Гость (31/01/2015 23:18)   <#>

Кстати, да. Смутно припоминается факт из QRNG-тестов: скорость urandom'а не зависит от random'а, который пополяет тот или иной HRNG (QRNG). Если в havege так же, то скорость urandom'а не будет иной по сравнению с тем, когда никакого havege нет в системе. Кажется, проблемы со скоростью (ограничение в 4MB/s) объяснялись какими-то внутренними ограничениями софтварных интерфейсов этих псевдоустройств (/dev/urandom).


Вспоминается история с RC4 [1], [2]. ☺
— unknown (31/01/2015 23:34)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Хотел его упомянуть, но не стал усложнять. Вы, как всегда, удачно нашли готовые посты для ответа. ☺
— Гость (01/02/2015 00:15)   <#>

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


Как-то так:

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

Какой смысл давать на каждый чих сотни ссылок?
Должен же кто-то упорядочивать информацию. Например, помнить и уметь искать даже мои старые комменты лучше меня самого.

Должность археорниса архивариуса обязывает. Обычно люди решают прямую задачу: к создаваемому документу/комментарию написать теги/описание. Я решаю в меру возможностей своей памяти обратную: по тегу/описанию найти конкретные посты в БД. Обратная сложнее. ☺
— unknown (01/02/2015 01:03)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

У вас вообще масса редковстречающихся полезных качеств ☺. Вас бы посылать на предварительное заваливание каких-нибудь докладов или работ — испытание spiore'ом как предварительный различитель. Правда, вредные качества обычно тоже вытекают из полезных, если довести всё совсем до абсурда: применять не к месту, перебарщивать не в меру. Это не про вас конкретно, это я и о себе так часто думаю в порядке профилактической самокритики :)
— Гость (01/02/2015 02:16)   <#>

Я недавно тут накаркал лишнего, после чего прилетел аист машина времени и перебросила pgpru.com на 15 лет вперёд (надеюсь, что до НИСТ дело всё же не дойдёт). В общем, пока я ругался на PC и поминал Голдрайха, мне предложили побыть мудаком по ту сторону баррикад. Работа была достаточно близкой к нашим темам, плюс человека знаю, который попросил, отказываться было неудобно. Насколько представляю расхожие правила по предыдущим конференциям, там три рецензента, и если хоть один поставит не высшую оценку работе, комитет её денониминирует с докладов на постеры. По всему QCS это топ-1 в мире, желающих туда попасть хоть жопой жуй, поэтому с критериями отбора не церемонятся. Короче, моя интуиция мне подсказывает, что работа высший балл не получит несмотря на то, что один из соавторов — безусловный топ, а другой хорошо известен но публикует нереально много слабых работ. Тем временем, вполне возможно, что они сейчас также сидят и судят на принятие мою работу. ☺

Доклад эта работа не получила. Моя тоже. В соавторстве топ был, надо мной потом коллеги стебались:

— А-ха-ха, ты, получается, зарезал самого [censored]? Ну ты даёшь...
— Ну я не виноват, что конкретна эта его работа в соавторстве с [censored] на уровень самого [censored] не тянет, он туда просто вписался.

P.S. [censored] — человек в нашей области типа Шамира по уровеню вклада/известности. Фамилии называть не буду, но они хорошо известны, в т.ч. здесь многократно упоминались. В науке принято срать в карму тайно. Перельмана на них нет.


Конечно, у всего есть обратная сторона медали.
— Гость (01/02/2015 12:32)   <#>

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