Привет, %username%, я уверен, что да. И в наших с тобой силах сделать это реальностью.
Этот пост навеян вот этим обсуждением, где порой доходило до ксеноморфов. У нас же всё будет проще и надежней (вдруг ксеноморфа забудут покормить?)
Ликбез
- Шифрование диска обычно производится симметричным алгоритмом вроде AES с помощью ключа, максимальный размер которого на апрель 2015 года редко превышает 32 байта (256 бит)
- На сегодняшний день не существует документированных доказательств восстановления перезаписанных данных
- Ключом шифрования контейнера чаще всего является случайная последовательность байт, а уже её шифруют с помощью вашего пароля
- Эта последовательность байт вместе со служебной информацией редко больше 1 кб. Такое количество данных можно за 10 секунд переписать спец методами несколько тысяч раз
Таким образом, при условии неуязвимости протоколов шифрования дисков и алгоритмов вам достаточно гарантировано уничтожить заголовок контейнера и все бекапы заголовка, чтобы навсегда распрощаться с любым объемом зашифрованных данных.
Truecrypt
Несмотря на то, что проект мертв, дело его живет.
Update Apr 2, 2015: Phase II complete. TrueCrypt has been audited.
И так все догадывались, да и особо неоткуда там взяться заранее спланированной дырке, уж больно все реализации использующихся в нем алгоритмов давно известны. Это же не OpenSSL какой нить.
Итак, Truecrypt — это пример OpenSource программы, которой можно более-менее доверять шифровать большие объемы данных маленьким (физически) ключом. Даже так: Скорей всего, вы не настолько круты, что даже если вас поймают, то будут использовать гипотетические дырки в трукрипте, чтобы достать из вашего контейнера информацию.
VeraCrypt
Это OpenSource форк трукрипта, в который осторожно добавляют новые фичи дабы не смутить вновь прибывших. Например, они после аудита трукрипта увеличили количество раундов хэширования пароля во много раз так, что ждать монтирования теперь приходится несколько секунд. Брутфорсить пароль, соответственно, сложней во столько же раз +-.
Так вот, у этих товарищей можно попросить сделать фичу безопасного быстрого удаления заголовка контейнера (и его бекапа) и такой запрос даже уже есть
Нужно просто зайти и проголосовать.
И у нас будет пригодный для практического применения бесплатный быстрый способ удалять данные навсегда. Правда ведь хорошо?
Так что, голосуем, не стесняемся.
Комментарии (42)
berez
27.04.2015 11:02при условии неуязвимости протоколов шифрования дисков и алгоритмов вам достаточно гарантировано уничтожить заголовок контейнера и все его бекапы
Двусмысленная фраза. Бэкапы чего — заголовка или самого контейнера? По смыслу — заголовка, а по грамматике — контейнера.
На самом деле, конечно, все не так радужно. Условий тут несколько больше:
— в компьютере нет аппаратных закладок (не обязательно уровня шпионских девайсов: например, беспроводная клавиатура не только общается с компьютером, но и орет все ваши введенные тексты-явки-пароли в прямой эфир в радиусе как минимум десятка метров). Против «красной кнопки» такой перехват не поможет, но только если код реализован корректно (см. ниже).
— в реализации удаления заголовков нет багов. Ситуация усугубляется тем, что код «красной кнопки» вызывается исключительно редко (практически — один раз), поэтому он, фактически, не тестируется. Даже очевидные логические ошибки могут жить в таком коде годами.
Scratch Автор
27.04.2015 11:16Предложение поправил. Что касается остального:
Я не отрицаю, что это довольно бюджетный вариант со своими недостатками. Но согласитесь, там писать-то особо нечего. Вся информация о расположении заголовка у программы есть, доступ к нему тоже. Работы на день с тестированием.berez
27.04.2015 13:10Да согласен, конечно. Все именно так.
Просто опыт показывает, что в таких вот редкоиспользуемых местах баги кроются чаще всего. Они не обязательно там будут сразу после написания: какую-нибудь дурацкую ошибку могут и при рефакторинге занести.
Чтобы такого не случилось, нужно не одноразовое тестирование, а полноценные юнит-тесты на эту конкретную функциональность. И чтобы все юнит-тесты гонялись перед каждым релизом.
tangro
27.04.2015 11:37+4>Может ли софтверное уничтожение данных быть лучше мощного магнита?
Нет, поскольку софтверное уничтожение данных требует наличие электричества, компьютера, ОС, софта, предварительно подготовленных данных и времени на уничтожение, а воздействие мощным магнитом мгновенно и не требует ничего, кроме HDD и магнита.Scratch Автор
27.04.2015 11:38А питается магнит чем? Бесперебойник обеспечит необходимое время и даже больше
tangro
27.04.2015 11:56+2Scratch Автор
27.04.2015 12:03Хорошо, принято. Но все равно дороже, чем нахаляву
vedenin1980
27.04.2015 12:51В данном случае торг не уместен. Когда к тебе вламываются маски шоу, вряд ли ты пожалеешь что отдал 20$ за магнит. На самом деле, лучше совмещать магнит/зашифрованный диск/soft удаление, если уж речь идет о действительно серьезных данных.
Scratch Автор
27.04.2015 13:04А где можно почитать об испытаниях магнита за 20$ на настоящем диске? Чтоб примерно так же подробно как с перезаписыванием
DrPass
27.04.2015 13:45+2У мощного неодимового магнита, по сравнению с софтверным уничтожением данных, есть один недостаток — его коэрцитивной силы в общем случае недостаточно для размагничивания поверхности жестких дисков.
tangro
27.04.2015 14:41А почему Википедия говорит, что диску достаточно 1700 Эрстедов, а неодимовые магниты дают до 12 000? А еще есть и самариевые — там до 40к.
Alexeyslav
28.04.2015 00:33+1Головка создает такое поле на расстоянии нескольких микрон от поверхности, чтобы создать такое поле с расстояния в сантиметр нужен магнит помощнее, раз так в тысячу а то и более.
tangro
28.04.2015 10:41Век живи — век учись!
Alexeyslav
28.04.2015 11:14Это не так чтобы невозможно, но я не уверен что неодимовый магнит сможет такое сделать. Скорей всего он начнет действовать на электрические и электромеханические цепи чем непосредственно на поверхность диска.
evans2094
28.04.2015 11:51«Торг в данном случае неуместен»
Цена вопроса конечно не 20 баксов, но катушка отлично пускает испульсом волну по диску (диск действительно волнами идет) а так же забивает положенную на крышку соленоида пятирублевую монету в панель подвесного потолка. Можно настроить уничтожение данных хоть на отключение питания, хоть на кнопку, хоть на смс. При этом после уничтожения диск выглядит снаружи как живой.
www.eraser.ru/htm/prise.htm
navion
27.04.2015 17:29USB-токен и киянка лишены этого недостатка.
rekby
27.04.2015 19:35это не надежно. Запросто можно сломать внешнюю пластиковую оболочку, а сам чип с ключем при этом останется целым.
У меня например токен собака погрызла хорошо так и ничего — продолжает работать.
На днях вот симку ломал — сами контакты от чипа отломались легко, а вот чип мне вручную сломать не получилось. К тому же киянка — это деревянный или резиновый молоток — с ним шансов достоверно разбить токен еще меньше, чем с кувалдой, которая так же гарантий не дает (пластик ломается, чип остается и потом припаевается к новым контактам).navion
28.04.2015 13:20Вариантов много. Можно ударить кувалдой и прижечь чип зажигалкой, а можно отдать команду на удаление или генерацию новых ключей и прикинувшись шлангом сказать «оно сломалось прямо перед вашим приходом».
rekby
28.04.2015 13:58прижечь чип зажигалкой — уже долго. Чип сначала выковырять надо после удара кувалдой.
Вот такая штука выглядит надежной: www.youtube.com/watch?v=GLxaVFBXbCk
но стоит дофига.
stargrave2
27.04.2015 12:45Безопасность шифрования настолько же сильна как и самый слабый компонент используемый в нём. Просто так взять и зашифровать AES-ом данные на диске не получится, так как AES это функция имеющая на входе 128 бит, ключ и 128 бит на выходе, не более. Вся соль проблемы это в каком режиме, как применять этот алгоритм шифрования.
Обычные режимы шифрования, такие как CBC применять не получится, так как для полнодискового шифрования особые требования: хочется иметь возможность чтения/записи/изменения любого блока диска в любое время (в CBC каждый последующий зашифрованный блок зависит от предыдущего). Если применить ECB режим то можно будет обращаться к любому блоку, но тут очевидна небезопасность этого решения, хоть внутри может быть использовать AES хоть 512.
На данный момент наиболее безопасный (в ущерб производительности) режим это XTS и именно на этот факт, на режим нужно в первую очередь обращать внимание. Подробнее обо всём этом есть статья: www.cypherpunks.ru/articles/full_disk_encryption.htmlScratch Автор
27.04.2015 12:58Он в трукрипте используется по умолчанию, я решил не писать пр него. Но да, метод шифрования тоже важен
amarao
27.04.2015 13:32+3Предполагается, что при отправке запроса на запись сектора, накопитель его перезапишет, а не выделит для новых данных новый блок с логическим ремапингом. HDD ремапинг делают редко (но делают!), а SSD — можно сказать, тем и живут, что только и репамят куда попало.
Secure-erase выполняется на SSD за единицы секунд, и ему я доверяю больше, чем «перезаписи» чего-либо на SSD. Хотя «доверяю больше» — величина относительная. А абсолютная (доверяю) находится в негативных значениях («не доверяю»).
Зато я очень доверяю шредеру. SD'шка после добротного шредера для SD куда более доверенное место для секретов, чем живой носитель в который что-то куда-то вроде бы записали.msuhanov
27.04.2015 18:46HDD ремапинг делают редко (но делают!)
В LUKS делают так:
Usually the master key comprises only 16 or 32 bytes. This small amount of data can easily be remapped as a whole to a reserved area. This action is taken by modern hard disk firmware, when a sector is likely to become unreadable due to mechanical wear. The original sectors become unaccessible and any traces of key data can’t be purged if necessary.
To counter this problem, LUKS uses the anti-forensic information splitter to artificially inflate the volume of the key, as with a bigger data set the probability that the whole data set is remapped drops exponentially.amarao
27.04.2015 19:17Это сработает для HDD, но для SSD, где «мусорные блоки» могут лежать годами, незатираемые.
Ivan_83
27.04.2015 15:05У GEOM ELI во FreeBSD есть бэкап этой служебки в виде отдельного файла, и есть ключик для быстрого удаления этой инфы с диска.
Если файл где то заначить то потом можно залить обратно и расшифровать, для этого тоже есть ключики в утилите управления.
mammuthus
27.04.2015 16:08>Таким образом, при условии неуязвимости протоколов шифрования дисков
С этим есть некоторые трудности.
vedenin1980
27.04.2015 18:14Вообще, если в чем проблема записать часть пароля на бумажку, остальную часть запомнить, а потом бумажку съесть/сжечь, а остальной пароль забыть? Ну это если 100% верить в шифрование данных на диске. Затраты одна бумажка, скорость — практически мгновенно.
qw1
27.04.2015 21:39после аудита трукрипта увеличили количество раундов хэширования пароля во много раз так, что ждать монтирования теперь приходится несколько секунд
Кто-нибудь доказал, что хеш-функция сюръективна?
Где гарантия, что после тысяч раундов хеширования значения не придут в относительно небольшое множество.
anton1234
27.04.2015 22:01+2при условии неуязвимости протоколов шифрования дисков и алгоритмов вам достаточно гарантировано уничтожить заголовок контейнера и все бекапы заголовка
Еще стоит добавить допущение, что мы полностью доверяем ОС.
В качестве примера теории заговора:
Truecrypt идеально надежен. Он пройдет любой аудит на 5. Авторы мужественно отказались сотрудничать с правительством. Но это и не нужно. Достаточно попросить MS добавить в свою ОС код, который будет копировать ваши данные в момент когда они расшифрованы. Разработчики truecrypt узнав об этом сделали все возможное, чтобы их продуктом никто не пользовался. Ведь чувство ложной защищенности особенно опасно.Scratch Автор
27.04.2015 22:03-1Куда копировать? Это ведь все отслеживается элементарными средствами. Разве что, сам ключ куда-нибудь в район биоса, но это тоже можно отследить
anton1234
27.04.2015 22:41Это грубый пример, который не претендует на истину. Но на мой взгляд проверив код truecrypt нельзя 100% гарантировать надежность шифрования им данных, т.к. исполняется он не в вакууме. И по большому счету спец службам гораздо логичнее идти именно в MS, на который у них есть и рычаги давления да и договоренности наверное.
Поэтому если говорить о конкретных программных продуктах, то безопасное шифрование нужно искать в линукс\фре… или еще чем-то более редком. Чем кастомнее будет решение тем больше у него шансов не быть вскрытым в обозримом будущем.
Equin0x
28.04.2015 00:02-1Интересно, каково значение точки Кюри покрытия современных дисков? Пиропатрон и корпус из термита — наше все )
evans2094
28.04.2015 11:44Сгоревшая серверная вместе со зданием, статья за умышленный поджог (человеку чья подпись стояит под актом о закупке данного девайса и ответственному за противопожарку точно) и т.д.
Хотя с таким уровнем паранойи скорее всего не посадят, а назначат принудительное лечение.
c0yc
Доверие есть только к TrueCrypt 7.1a который один из самых последних + проверенных. Слив разработчиков TC довольно сильно напряг. Другим доверия нет, тк просматривать и анализировать тысячи строк кода желания нет. Да и на посторонних сайтах качать версии TrueCrypt`а тоже боязно, кто знает кто и что туда засунет. Хорошо что данная версия у меня задублирована везде где только можно.
Доверия VeraCrypt нет, тк разработчики особо и не скрывают свои личности -> давление и бекдоры. «Автор — французский консультант в области информационной безопасности Моунир Идрасси (Mounir Idrassi).»
Scratch Автор
Всему своё время, я уверен авторы veraCrypt тоже пройдут аудит в свое время. К тому же, аудитить надо будет только diff между 7.1a и их версией, а это все равно меньше работы