Comments 33
Для адекватной защиты информации шифрование должно быть полнодисковым. Как минимум на десктопе точно. Иначе очень сложно предсказать, какие хвосты от информации, хранящейся в зашифрованном контейнере, у нас останутся в незашифрованной части системы (временные файлы, кэши, резервные копии, куски данных в файлах подкачки и гибернации и т.д. и т.п.)
VeraCrypt, кстати, умеет шифровать загрузочный диск аж из EFI, делал такое один раз, давно, правда, и вот про это, к сожалению, не написано.Единственное преимущество Vera/TrueCrypt перед LUKS (или встроенным шифрованием ZFS, если её используем) - это те самые скрытые контейнеры для обеспечения plausible deniability. Но в реальной жизни, чтобы обеспечить эту plausible deniability, надо постоянно, помимо работы с реальными данными в скрытом контейнере, ещё и обновлять данные в фейковом. И не просто формально, а так, чтобы они выглядели убедительно. Тем более это малореально, если мы шифруем не весь диск (см. п. 1), т.к. тут нас выдадут тупо списки последних открытых файлов, история открытых папок и т.п. Я вижу очень мало сценариев, когда кто-то будет так заморачиваться.
Потдерживаю LUKS. Есть неплохая статья про монтирование LUKS диска автоматически без сохранения ключа на машине. Решает проблему автоматического монтирования и безопасности при физическом воровстве девайса.
https://withblue.ink/2020/01/19/auto-mounting-encrypted-drives-with-a-remote-key-on-linux.html#commento-login-box-container
У LUKS, к слову, есть один громадный недостаток, который я обнаружил, когда на днях мне в голову пришла мысль "а не спрыгнуть ли мне с Windows и BitLocker?". LUKS не умеет шифровать таким образом, чтобы для расшифровки нужно было несколько факторов одновременно.
Поясню: BitLocker позволяет настроить шифрование таким образом, что для расшифровки потребуется наличие ключевого файла на внешнем накопителе и пин-кода (который знает пользователь). Если одного из этих факторов не будет (ключевой файл уничтожен / не удалось выбить пин-код из пользователя), расшифровать накопитель не получится.
LUKS тоже позволяет добавить и пароль, и ключевой файл, но они действуют как независимые друг от друга предохранители. Накопитель можно будет расшифровать ключевым файлом или паролем. Атакующему достаточно завладеть одним из двух.
Это какой-то позор (с) У нас в вебе вовсю двухфакторная авторизация, а самое популярное средство для дискового шифрования в Linux двухфакторную авторизацию не умеет.
Можно доступ к ключу закрыть паролем. У меня эту задачу для тех случаев, когда я физически сам разблокирую зашифрованный диск (не удалённо), решает флэшка с аппаратным шифрованием (Datashur), на которой и лежат ключики. Для удалённой разблокировки тем более масса вариантов.
P.S. Нагуглился ещё один вариант, сам не пробовал. Вместо ключа сохранить заголовок LUKS на отдельном носителе (detached header, так, оказывается, можно). А в password slot записать пароль. В результате этот заголовок будет выполнять роль ключа, который вы должны иметь, чтобы потом ввести пароль.
Флешка с шифрованием это вариант, но насколько оно там шифрование, вот в чём вопрос. Я помню историю с приложением под Android, автор которого заявлял шифрование AES-256, все дела, а в реальности данные шифровались обычным XOR...
Отсоединённый заголовок это хорошо, по описанию - прямо то, что надо. Вот бы ещё это всё через GUI, было бы вообще счастье.
Хотя, вот, Ubuntu двигается в нужном направлении: они хотят в инсталляторе предлагать не только LUKS с паролем, но и добавить опцию "LUKS с авторасшифровкой с помощью TPM".
но насколько оно там шифрование, вот в чём вопрос.
Ну эти ребята уже много лет на рынке, ничего компрометирующего про них не слышно. Ну и, опять же, вопрос к модели рисков. Если основная угроза - российский товарищ майор, который ноут вместе с этой флэшкой изымет, - маловероятно, что в штате РОВД по Nскому району найдутся специалисты, умеющие эксплуатировать уязвимости экзотической заморской железки, даже если таковые в ней есть.
Пароль можно разделить на составные части и собирать из них скриптом.
Тут ограничено только фантазией - напримар 1/3 aws, 1/3 azure, 1/3 esp которая висит где-нибудть дома на wifi и отдает пароль по запросу.
Если ноут/PC физически изьят то часть по wifi будет недоступна. Плюс можно отрубить облака чтобы не отдавали их части пароля
Ограничение этого метода - не для загрузочного диска.
VeraCrypt, кстати, умеет шифровать загрузочный диск аж из EFI, делал такое один раз, давно, правда, и вот про это, к сожалению, не написано.
Только если используется Windows. По крайней мере так было пару лет назад.
надо постоянно, помимо работы с реальными данными в скрытом контейнере, ещё и обновлять данные в фейковом. И не просто формально, а так, чтобы они выглядели убедительно.
Существуют и холодные данные, хранение которых на зашифрованном разделе может выглядеть убедительно — то что выглядит как рабочая документация, сканы личных документов, личные неприличные фотографии :)
Но у True/VeraCrypt есть другой, на мой взгляд более серьёзный недостаток — принципиальный отказ от поддержки TPM, что означает хранение ключей в оперативной памяти, откуда, их теоретически проще вытащить, например с помощью уязвимостей Spectre.
Но у True/VeraCrypt есть другой, на мой взгляд более серьёзный недостаток — принципиальный отказ от поддержки TPM, что означает хранение ключей в оперативной памяти
Абсолютно любой софт, с поддержкой TPM или без, будет хранить мастер-ключ в оперативной памяти. Вы же не ожидаете, что крохотный TPM, подключенный к шине в 33 МГц, будет способен шифровать трафик современных дисков?
TPM всегда используется только для расшифровки мастер-ключа, которым уже шифруются данные.
TPM всегда используется только для расшифровки мастер-ключа, которым уже шифруются данные.
Что ж, я был лучшего мнения о TPM, почему-то считал, что благодаря наличию надежного хранилища ключей, он позволяет генерировать, хранить и относительно часто менять ключи шифрования данных, что позволило бы даже в случае единовременно снятого дампа получить ключ только от части секторов диска. По крайней мере это выглядело как логичный и вариант того, как это могло быть устроено. А в итоге получается что TPM может защитить от брутфорса и манипуляций с EFI, но не от дампа участка памяти с ключом. Тоже конечно полезные вещи, но как-то маловато.
От дампа памяти защищает, например, политика Windows "отключать DMA-устройства, которые подключены, когда компьютер заблокирован". Но она работает только если включён BitLocker.
TPM усложняет атакующему жизнь, лучше его использовать, чем не использовать. Атакующий не сможет подменить прошивку, не сможет отключить Secure Boot. Если у вас не включён Boot Guard (а он мало где включен), то без TPM вы не выстроите цепочку доверия, у вас корня доверия не будет. Вы не можете гарантировать, что в ваше отсутствие не была подменена прошивка системной платы. Ну, все же помнят историю, как зарубежный исследователь безопасности, приехав в Москву на конференцию, обнаружил в номере отеля неизвестного, который крутился около его ноутбука?
TPM очень полезен, когда компьютером пользуются разные пользователи. Если использовать шифрование с паролем, то придётся сообщить пароль всем этим пользователям, после чего любой из них загрузится с LiveCD, расшифрует известным паролем системный накопитель и получит доступ к профилям остальных пользователей, а также сможет сделать себя администратором. C TPM накопитель расшифруется только при штатной загрузке, причем, можно даже настроить автоматическую расшифровку. А дальше уже в бой вступает авторизация в ОС, которая пускает каждого пользователя лишь в свою учётку.
Очень сложно, знаете ли, конкурировать с инструкцией процессора, работающей на частоте в несколько ГГц и имеющей по экземпляру в каждом ядре. Лично у меня aes-xts работает на скорости 2.8 гигабайт в секунду на ядро.
С разделением ключей на области чисто теоретически такое реализовать можно (никаких принципиальных проблем нет), но я таких реализаций не видел. dm-crypt берет один мастер-ключ и реализует софтварное шифрование.
Про EFI и брутфорс - да, вы правы, именно такая модель угроз там и задумывалась.
Только если используется Windows. По крайней мере так было пару лет назад.
Возможно, я именно для Windows и делал, но мне казалось, что на уровне EFI это не должно было зависеть от ОС. Наверное, ошибался.
Но у True/VeraCrypt есть другой, на мой взгляд более серьёзный недостаток — принципиальный отказ от поддержки TPM
TPM при полнодисковом шифровании вполне поддерживается, только настраивается не через GUI.
Если внимательно посмотреть код, то можно и другие неочевидные возможности обнаружить, например, автоматическую расшифровку при наличии USB-накопителя с заданными VID/PID/SERIAL или расшифровку с помощью нажатия мышью на определённые участки графического изображения.
TPM при полнодисковом шифровании вполне поддерживается, только настраивается не через GUI.
А вот это реально удивительно, поскольку прямо на официальном сайте в разделе частых вопросов у них написано:
Some encryption programs use TPM to prevent attacks. Will VeraCrypt use it too?
No. Those programs use TPM to protect against attacks that require the attacker to have administrator privileges, or physical access to the computer, and the attacker needs you to use the computer after such an access. However, if any of these conditions is met, it is actually impossible to secure the computer (see below) and, therefore, you must stop using it (instead of relying on TPM).
Этот абзац ещё из TrueCrypt тянется, только заменили TrueCrypt на VeraCrypt.
Поддержку TPM и прочих скрытых фич к EFI-загрузчику прикручивал доброволец, как видно, он даже поддержку TPM 2.0 не добавил, так что, видимо, это всё так и осталось полуофициально, а знание о том, как это настроить, вообще содержится на стороннем русскоязычном форуме. Проще заявить "поддержки нет", чем описывать эти шаманства и ограничения.
Официально-то и поддержки скрытой ОС на GPT-разметке нет, но технически она есть.
В общем, всё это реализовано на уровне "вроде, работает, но неофициально и через пляски с бубном". Впрочем, если пользователь сумел до этого знания добраться, вероятно, он готов.
"Кажется, что хорошая идея выбирать значение PIM, не сильно отличающиеся от рекомендованного разрабами. В таком случае специалисту, который будет пытаться расшифровать ваши данные, придется перебирать не просто пароли, а еще и количество итераций" - почему вы считаете, что выбрав не сильно отличающийся от рекомендованного PIM, вы значительно повышаете сложность перебора (в отличии от ситуации, когда PIM наоборот, сильно отличается от рекомендуемого)?
почему вы считаете, что выбрав не сильно отличающийся от рекомендованного PIM, вы значительно повышаете сложность перебора
Видимо, имелось в виду - не слишком отличающийся по порядку величины в меньшую сторону - по крайней мере мне так удалось расшифровать эту фразу, чтобы она имела смысл :).
Интересно узнать, каким оно может вообще быть (это число PIM), каковы требования к его выбору и чем они обусловлены?
Более чем уверен что ситуация аналогичная с циклическим (возможно это так называется) хешированием паролей, к примеру, на разных сайтах. Для исключения использования радужных таблиц. Если условно итерации 10, то нужно будет потратить на каждый из возможных паролей: кол-во_паролей * 10 единиц времени. В случае если итераций 100, уже кол-во_паролей * 100. А вот если не знать PIM (и он не установлен как по умолчанию), тут уже одному богу известно сколько времени на это уйдет. Могу предположить что минимальные значения рассчитывались из того на сколько сильно возрастет время перебора пароля и как сильно упадет время доступа к данным.
Из документации, хоть автор и упомянул об этом:
Когда указано значение PIM, количество итераций рассчитывается следующим образом:
Для системного шифрования, которое не использует SHA-512 или Whirlpool: Итерации = PIM x 2048
Для системного шифрования, использующого SHA-512 или Whirlpool, несистемное шифрование и файловые контейнеры: Итерации = 15000 + (PIM x 1000)
До версии 1.12 безопасность тома VeraCrypt основывалась только на надежности пароля, потому что VeraCrypt использовала фиксированное количество итераций.
С введением PIM, VeraCrypt имеет 2-мерное пространство безопасности для томов, основанных на паре (пароль, PIM). Это обеспечивает большую гибкость для настройки желаемого уровня безопасности, а также контроля производительности операции монтирования/загрузки.
Чуть более подробнее тут
Немного не по теме: а нет ли средства шифровать на лету данные в Яндекс диске, не создавая костыли из отдельного тома и локальной синхронизации с папкой Яндекса ?
Я с dropbox использовал encfs. В папке dropbox находится контейнер, а когда нужны данные, он монтируется куда-то вне этой папки. Было очень удобно, что под андроид было приложение, которое умело работать с контейнерами encfs из dropbox. Но, к сожалению, приложение это забросили, а dropbox сменил api видимо и перестало работать.
Я думаю вы и описанный выше truecrypt можете так же использовать - зашифрованный контейнер в папке я.диска, а монтируете вы его куда-то вне этой папки.
Есть rclone. Умеет и в шифрование и в сжатие и в объединение нескольких удалённых хранилищ в одно.
Я правильно понимаю, что они может вместо программы яндекс диска самостоятельно подгружать данные в облако яндекса?
Может. Но несколько лет назад Яндекс специально ломал у себя поддержку rclone (и заодно стандарта WebDAV), чтобы народ, не дай Бог, не использовал в коммерческих целях дешёвый Диск вместо более дорогого хранилища Яндекс.Облака. Не знаю, как так сейчас с этим, давно не использовал.
настроил, работает, но скорость стремится к нулю :(
Получается, Яндекс принципиально против подобных решений, с шифрованием
Они не против шифрования, а против того, чтобы мелкий бизнес вместо объектного хранилища в Яндекс.Облаке, где 1 Тб получается в среднем тысячи 3 (в зависимости от исх. трафика по-разному) в месяц, покупал Диск по 400 рублей в месяц за тот же 1 Тб :) Поэтому и блокируют инструменты, дающие возможность просто примонтировать Диск на сервер или использовать его для автоматизированных бекапов с сервера.
P.S. Вообще, если нужно нормальное облачное хранилище, работающее по стандартным протоколам, но при этом дешёвое, - посмотрите на Backblaze B2. Поддерживает как S3, так и свой протокол B2, который много каким софтом тоже реализован. Если возможность оплаты зарубежных сервисов есть (уж за полтора года, надеюсь, все этот вопрос решили) - то отличный вариант.
До сих пор на хабре создаются статьи с инструкцией как шифровать что-то с помощью truecrypt.
Диски, зашифрованные TrueCrypt/VeraCrypt, теряют производительность в сравнении с шифрованием в DiskCryptor
Привет, можно ссылку на бенчмарки или сравнение, которое можно повторить? (самому не удалось найти)
Я когда-то сам замерял и сравнил, понял, что DC быстрее, и с тех пор пользую его, замеры не сохранились. Но вот например https://github.com/veracrypt/VeraCrypt/issues/136
Просто шифруем файлы в Linux с помощью Truecrypt и Veracrypt