Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
Ну, AES-CBC уже на самом деле редкость для нормальных программ, везде уже XTS/GCM используется. А вот встраивание бекдоров в бутлоадер\биос, пока комп не у вас, это да, страшновато.
Для программ — да. А для встроенных в операционку средств? Насколько я понял из статей, Bitlocker использует AES-CBC. Более того, средства для шифрования по умолчанию в Ubuntu тоже используют AES-CBC. А где используется XTS/GCM?
XTS — Трукрипт, из встроенных- ZFS использует GCM
LUKS, в той же убунте вполне доступен. А encfs вообще может подписывать зашифрованные данные, так что никакие модификации незамеченными не пройдут. (У него есть свои особенности — это не block-level шифрование, а file-level, но удобен очень — можно директорию-оригинал разместить в Dropbox, зашифрованные файлики с нечитаемыми именами будут синхронизироваться, а где стоит encfs можно прозрачно получать их в расшифрованном виде.)
LUKS — контейнер. Шифрование в контейнере чаще всего как раз AES-CBC.
Поправка: AES-CBC-ESSIV, последний увеличивает вероятность обнаружения описанной атаки.
Уже давно AES-XTS-PLAIN по умолчанию. А выбрать его руками можно было с 2007 года.
man cryptsetup сообщает иное:
Вот что создаётся по умолчанию в Altlinux p7 в процессе установки:
Могу проверить ещё в Ubuntu 14...., но не сейчас.
--cipher, -c
set cipher specification string.
Default mode is configurable during compilation, you can see compiled-in default using cryptsetup --help. If not changed, the default is for plain dm-crypt and LUKS mappings "aes-cbc-essiv:sha256".Вот что создаётся по умолчанию в Altlinux p7 в процессе установки:
[root@sd ~]# cryptsetup luksDump /dev/md1
LUKS header information for /dev/md1
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256Могу проверить ещё в Ubuntu 14...., но не сейчас.
xts по умолчанию в cryptsetup 1.6+ (в debian wheezy, например, 1.4.3; в centos6 — 1.2.0), но установщик убунты может по умолчанию предлагать xts при создании зашифрованного тома через него. Кто создаёт тома через cryptsetup должен осознавать, что означают различные параметры.
А теперь внимательно читаем man cryptsetup:
В Ubuntu 14.04.1 опции сборки cryptsetup другие, не более.
- В Altlinux p7
Default mode is configurable during compilation
- В Ubuntu 14.04.1
Set the cipher specification string.
cryptsetup --help shows the compiled-in defaults. The current default in the distributed sources is «aes-cbc-essiv:sha256» for both plain dm-crypt and LUKS.
В Ubuntu 14.04.1 опции сборки cryptsetup другие, не более.
Иии?.. Как это противоречит тому, что cryptsetup 1.6+ имеет aes-xts-plain64 по умолчанию при сборке (если иного не указано при запуске ./configure)?
Ещё раз. Медленно. Внимательно читаем.
Английским по белому написано: «The current default in the distributed sources is «aes-cbc-essiv:sha256»»
Если не умеешь читать английский текст и не умеешь пользоваться переводчиком, вот перевод:
«Текущее умолчание в исходниках — «aes-cbc-essiv:sha256»».
Английским по белому написано: «The current default in the distributed sources is «aes-cbc-essiv:sha256»»
Если не умеешь читать английский текст и не умеешь пользоваться переводчиком, вот перевод:
«Текущее умолчание в исходниках — «aes-cbc-essiv:sha256»».
1. Не хамите.
2. Можно было сходить, например, по адресу gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions в пункт 5.16, где русским по белому сказано
Или, например, в man/cryptsetup.8 от версии 1.6.7, где сказано:
Или в release notes от 1.6.0, где сказано:
Если у вас в altlinux p7 версия cryptsetup младше 1.6 или он собран с --with-luks1-mode=cbc-essiv:sha256 это ваши личные половые трудности. Аналогично с ubuntu.
2. Можно было сходить, например, по адресу gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions в пункт 5.16, где русским по белому сказано
From version 1.6.0 of cryptsetup onwards, aes-xts-plain64 is the default for LUKS.
Или, например, в man/cryptsetup.8 от версии 1.6.7, где сказано:
cryptsetup --help shows the compiled-in defaults.
The current default in the distributed sources is
«aes-cbc-essiv:sha256» for plain dm-crypt and
«aes-xts-plain64» for LUKS.
Или в release notes от 1.6.0, где сказано:
* Change LUKS default cipher to to use XTS encryption mode,
aes-xts-plain64 (i.e. using AES128-XTS).
XTS mode becomes standard in hard disk encryption.
You can still use any old mode:
— compile cryptsetup with old default:
configure --with-luks1-cipher=aes --with-luks1-mode=cbc-essiv:sha256 --with-luks1-keybits=256
— format LUKS device with old default:
cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 <device>
Если у вас в altlinux p7 версия cryptsetup младше 1.6 или он собран с --with-luks1-mode=cbc-essiv:sha256 это ваши личные половые трудности. Аналогично с ubuntu.
$ cryptsetup --version
cryptsetup 1.6.1
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=«Ubuntu 14.04.1 LTS»
cryptsetup 1.6.1
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=«Ubuntu 14.04.1 LTS»
версия cryptsetup младше 1.6 или он собран с --with-luks1-mode=cbc-essiv:sha256Добавлю ещё один вероятный вариант, man/cryptsetup.8 могли не привести в соответствие с реальными умолчаниями.
Какой тип тома в реальности создаётся по умолчанию cryptsetup 1.6.1 на ubuntu 14.04.1? Если aes-xts-plain64, то он собирался без указания
--with-luks1-mode=cbc-essiv:sha256. Если cbc-essiv, то это вопрос к мейнтейнерам, почему они используют такие параметры сборки.Вот в Ubuntu 14.04.1 LTS действительно по умолчанию aes-xts-plain64, но хэш sha1.
$ cryptsetup --help | tail -n 4
Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/urandom
В макоси используется XTS и для file vault и для криптованных дисков.
Подробно такая атака описана в другой статье, там же — практическая реализация для Ubuntu 12.04.И там же написано, что 12.10 использует xts по умолчанию.
Спасибо, далек от информационной безопасности, про трюк с загрузчиком не знал. Хотя после того как все объяснено вроде очевидно.
На буке диск зашифрован на случай кражи в основном так что риск не велик но теперь знаю что риск есть.
На буке диск зашифрован на случай кражи в основном так что риск не велик но теперь знаю что риск есть.
- Хранить флешку (SD) с установочником чистой системы и переключателем только для чтения «ON» и минимальным набором нужного софта без конфигов
- Грузится только с нее и работать только в ОЗУ
- иметь в ноуте самый мелкий SSD с бутафорской, но рабочей системой
Затем как было в одной статье, если попросили ноутбук, «выключаем» или отдаем уже выключенный. Пусть резвятся и ставят трояны. Затем, когда надо работать, пихаем флешку, ставим систему и работаем в ОЗУ.
Нужен ноут со с нежрущим процессором, пассивным охлаждением и хорошей батарейкой. Если пойти дальше — заменить экран на E-Ink, ну и «припаять внутрь», чтобы при потере питания встроенный LiIon таблетка затирала на нем данные (E-Ink же).
Хорошее решение, но требует специфичной операционки (с флешки хорошо работает Fedora, а вот винда или OSX с флешки работают не то чтобы очень хорошо). Для большинства пользователей такой способ не подойдет?
А если запихнут троян в биос? Были же прецеденты
А есть хотя бы один «живой» дистрибутив с графической средой, в которой можно хоть как-то решать повседневные задачи, но в котором полностью исключена возможность автоматического (без участия пользователя) запуска недоверенных программ с HDD/SSD в процессе загрузки?
Это зависит от того, какие программы понимать как недоверенные.
Большинство дистрибутивов GNU/Linux реализуют функционал по ограничению запуска приложений и скриптов — см. SELinux. Более того, можно задать доступ каждому приложению к конкретным ресурсам и ни к каким другим.
Большинство дистрибутивов GNU/Linux реализуют функционал по ограничению запуска приложений и скриптов — см. SELinux. Более того, можно задать доступ каждому приложению к конкретным ресурсам и ни к каким другим.
Это зависит от того, какие программы понимать как недоверенные.
Любые, которые может разместить атакующий на накопителе компьютера пользователя. Вопрос был с подвохом, если что: в сообщении ранее речь шла о том, что можно обмануть атакующего, который имел возможность записать на накопитель компьютера любой свой бекдор, путем загрузки с USB-накопителя. Предполагается, что «живой» дистрибутив будет функционировать независимо от программ на HDD/SSD, с которым проводил манипуляции атакующий, однако это не так.
Большинство решений по шифрованию жесткого диска используют алгоритм AES в блочном режиме CBC.
Ну, естественно, если использовать совершенно не предназначенный для этого режим, вы получите проблемы с безопасностью. Снова встаёт вопрос качества ПО от Microsoft.
Нормальный и вменяемый LUKS, например, по умолчанию испольует специально разработанный для шифрования дисков режим XTS (с блочным шифром AES).
Хотя и в XTS есть проблемы, но по крайней мере проблема, когда злодей знает открытый текст, решена.
А в каких мейнстрим дистрибутивах по умолчанию используется LUKS?
«По умолчанию» в популярных дистрибутивах никакое шифрование не используется. В убунте сделали какой-то интерфейс, но я сомневаюсь в его качестве.
В инсталляторе Debian (и Ubuntu, если использовать не этот красивый и бестолковый гуй, а debian-installer) LUKS можно настроить «из коробки», то есть, он там не по умолчанию, но опция есть прямо сразу.
Судя по документации, в Fedora то же самое, Anaconda (инсталлятор) умеет ставить на LUKS.
А вообще LUKS поддерживается в любом, и инструкции есть для всех дистрибутивов.
В инсталляторе Debian (и Ubuntu, если использовать не этот красивый и бестолковый гуй, а debian-installer) LUKS можно настроить «из коробки», то есть, он там не по умолчанию, но опция есть прямо сразу.
Судя по документации, в Fedora то же самое, Anaconda (инсталлятор) умеет ставить на LUKS.
А вообще LUKS поддерживается в любом, и инструкции есть для всех дистрибутивов.
При установке почти в любом. В инсталляторе при ручной разбивке диска создаёшь зашифрованный том, и всё.
Нормальный и вменяемый LUKS, например
… стал использовать XTS всего-то меньше трех лет назад. Тогда как битлокер в Vista/Win7 позволял использовать дополнительную защиту, решающую проблему. Так что не надо про качество.
Вчера была опубликована статья, в которой, не без помощи Microsoft, раскрываются интересные подробности о внутренностях BitLocker. Статья длинная и ее содержимое можно резюмировать как «в целом выглядит адекватно, явных уязвимостей вроде не видно».
Помнится, как-то решил поставить его на семерку — но так и не получилось настроить на авторизацию по паролю как в трукрипте и аналогах. Плюнул и поставил трукрипт.
Это же самый удобный и очевидный режим авторизации, из каких соображений его не добавили?
Он на самом деле есть, просто действительно включается не то чтобы просто :). Там нужно залезть в политики и вручную разрешить использовать пароль для ввода с клавиатуры.
Сделано так исходя из соображений безопасности: для низкоквалифицированных сотрудников крупных компаний проще носить флешку на брелке для ключей, чем запоминать пароль. И если сделать простой ввода пароля… Бумажки рядом с мониторами все видели? :)
Сделано так исходя из соображений безопасности: для низкоквалифицированных сотрудников крупных компаний проще носить флешку на брелке для ключей, чем запоминать пароль. И если сделать простой ввода пароля… Бумажки рядом с мониторами все видели? :)
Когда вы запускаете компьютер с Linux, Windows или OSX, вначале стартует некий код операционной системы
…
Атака «evil maid» заключается в том, что backdoor, отсылающий злоумышленнику всю необходимую информацию, встраивается в запрашивающий пароль код.
Между тем, в статье написано «Mac OS X and Linux’s disk encryption systems are entirely vulnerable to this attack, but Windows, when running BitLocker, is not.» А у вас этот момент упущен.
А много ли толку в защите от подмены загрузчика, если там диск зашифрован в режиме CBC, который уязвим к подмене данных на самом зашифрованном разделе в случае знания открытого текста, а его-то все знают — например, у всех есть одинаковый ntoskrnl.dll (или как он там называется)?
1. На Vista/Win7 не уязвим (если правильно настроен).
2. Точность надо соблюдать в любом случае. :)
3. Ну и лично я считаю, что всегда полезно придерживаться правила «если девайс физически попал в руки врагу, он скомпрометирован».
2. Точность надо соблюдать в любом случае. :)
3. Ну и лично я считаю, что всегда полезно придерживаться правила «если девайс физически попал в руки врагу, он скомпрометирован».
Поясните, какие именно средства делают Win7 неуязвимым к подмене каждого второго блока CBC?
Полагаю, это механизм windows file protection, который проверяет целостность системных файлов и, в случае их подмены, восстанавливает из shadow копии. К сожалению, для атаки можно подменять не только системные файлы, но и множество других — всякие autorun итд. Разработчики из соседнего отдела нашептывают что задача это нетривиальная, но само знание о возможности такой атаки ценно.
Насколько я понимаю, там добавлен дополнительный слой защиты (diffuser), который специально предназначен для противодействия таким атакам — css.csail.mit.edu/6.858/2012/readings/bitlocker.pdf
Так убрали ж диффузер в новых версиях?
Да. Потому я и пишу — Vista/Win7. :)
Но вот ещё занятный момент, к вопросу, почему MS не стали имплементировать XTS — csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_comments.pdf
В общем, похоже, что в MS попросту не считают, что XTS решает проблему.
Но вот ещё занятный момент, к вопросу, почему MS не стали имплементировать XTS — csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_comments.pdf
В общем, похоже, что в MS попросту не считают, что XTS решает проблему.
«Пусть не решит он всех проблем...»
Это совершенно не отменяет того факта, что CBC для шифрования диска не подходит.
Полностью проблема оффлайновой модификации шифртекста не решается без использования MAC. А поскольку под них тоже требуется что-то зарезервировать, на хорошо-зашифрованном-диске места будет явно меньше, чем на незашифрованном, а заодно конверсия незашифрованного диска в зашифрованный «на лету» становится сложно реализуемой. Думаю, поэтому-то программы шифрования с MAC и не особенно популярны.
Это совершенно не отменяет того факта, что CBC для шифрования диска не подходит.
Полностью проблема оффлайновой модификации шифртекста не решается без использования MAC. А поскольку под них тоже требуется что-то зарезервировать, на хорошо-зашифрованном-диске места будет явно меньше, чем на незашифрованном, а заодно конверсия незашифрованного диска в зашифрованный «на лету» становится сложно реализуемой. Думаю, поэтому-то программы шифрования с MAC и не особенно популярны.
Спасибо большое, исправил!
в аэропорту солнечной Испании у вас на 10 минут попросили досмотреть ноутбук с зашифрованным жестким диском
Ну уж Вы загнули! В Европе весь досмотр сводится к просьбе открыть ноут, чтобы убедиться, что это не муляж для провоза контрабанды, и то не всегда. Да и по законодательству любой досмотр должен проводиться строго в присутствии владельца. Так что никаких «дайте на 10 минут» быть не может. Не говоря уж о том, чтобы подсадить какой-нибудь вирус…
Вот Израиль — более вероятный кандидат. Там теоретически и ноут могут попросить и вернуть его вам по винтикам, если заподозрят что-нибудь. Но вроде бы ни с кем не приключалось.
В Британии любая, даже самая совершенная система шифрования тупо скомпроментирована законодательством. Вас вежливо попросят ввести пароль или ключ для досмотра содержимого. При отказе или невозможности проделать оную операцию вас проводят в КПЗ для дальнейшего разбирательства.
В России также при пересечении границы могут потребовать средства хранения данных для досмотра. Хотя на счет обязательного предоставления ключа для расшифровки не уверен. Последний и единственный раз у меня проверяли дискеты лет этак N-дцать назад.
Средства обеспечения безопасности для личного пользования — они в первую очередь от любопытствующих, случайных утечек и воров. Если случилось постановление Английского суда выдать ключ шифрования — то это уже переходит в юридическю плоскость и выходит за рамки хабра :).
В Британии, тем не менее, не обязательно смогут что-то подменить, хотя и смогут прочитать.
Ключ, которым вы шифруете, не обязан совпадать с ключом, использующимся для проверки подписей. Ключ для расшифровки — вот, пожалуйста, читайте. А ключ для подписей они требовать по этому закону не могут.
Ключ, которым вы шифруете, не обязан совпадать с ключом, использующимся для проверки подписей. Ключ для расшифровки — вот, пожалуйста, читайте. А ключ для подписей они требовать по этому закону не могут.
> Но вроде бы ни с кем не приключалось.
lilyasussman.com/2009/11/30/im-sorry-but-we-blew-up-your-laptop-welcome-to-israel
lilyasussman.com/2009/11/30/im-sorry-but-we-blew-up-your-laptop-welcome-to-israel
Хотел написать про Evil Maid, буткиты и Cold Boot-атаки еще года два назад, но руки так и не дошли пока.
В общем, если кому-то интересно, то напишу статью.
Bitlocker частично защищен от этой атаки — его загрузчик проверяет собственную целостность (конечно, ничто не мешает поменять и код проверки — но это намного труднее), OSX и популярные дистрибутивы Linux не имеют даже такой защит.Не совсем так. Во-первых, есть специальные скрипты, которые проверяют целостность всего во время загрузки ОС. Во-вторых, есть Secure Boot, который частично может использоваться и как средство защиты от Evil Maid (скажем, пароль на изменение конфигурации UEFI). Вы можете сгенерировать свои ключи, подписать ими загрузчик и ядро, и не позволить внедрить чужие ключи обычным паролем на изменение конфигурации. В-третьих, есть TPM, с использованием которого можно шифровать rootfs, подписав ключ шифрования LUKS TPM и PCR-регистрами, таким образом, rootfs не расшифруется, если изменили загрузчик, ядро, initramfs, или даже параметры, передаваемые ядру.
В общем, если кому-то интересно, то напишу статью.
Правильно ли я понимаю, что если изменить один из блоков, воспользовавшись «уязвимостью» AES-CBC, то соседний с ним блок испортится?
Интересно почитать, архивы (AES) тоже *открывали по наличию стандартных файлов внутри.
Не проще ли оставить важные данные дома, и через VPN (что по душе) подключаться по мере необходимости?
А при себе на таможню ничего зашифрованного не иметь и тем самым не привлекать внимание. Если интерес все же возникнет, то какую реализацию не используй, а показывать что внутри придется.
Но ведь надо придумать что то 99,9% рабочее.
Не проще ли оставить важные данные дома, и через VPN (что по душе) подключаться по мере необходимости?
А при себе на таможню ничего зашифрованного не иметь и тем самым не привлекать внимание. Если интерес все же возникнет, то какую реализацию не используй, а показывать что внутри придется.
Второй закон Шамира: криптографию не сломают, ее обойдут.
Но ведь надо придумать что то 99,9% рабочее.
Большинство решений по шифрованию жесткого диска используют алгоритм AES в блочном режиме CBC. А у этого алгоритма есть забавная особенность.
Неудачная фраза, которая может привести в возникновению некорректного мема (и судя по комментариям он уже зарождается). Можно подумать, что проблема в AES или в сочетании AES-CBC. На самом-то деле проблема исключительно в CBC и подобную атаку «через блок» можно организовать для любого блочного алгоритма шифрования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атака «evil maid» на зашифрованный жесткий диск