Комментарии 70
Ну, AES-CBC уже на самом деле редкость для нормальных программ, везде уже XTS/GCM используется. А вот встраивание бекдоров в бутлоадер\биос, пока комп не у вас, это да, страшновато.
+6
Для программ — да. А для встроенных в операционку средств? Насколько я понял из статей, Bitlocker использует AES-CBC. Более того, средства для шифрования по умолчанию в Ubuntu тоже используют AES-CBC. А где используется XTS/GCM?
0
XTS — Трукрипт, из встроенных- ZFS использует GCM
0
LUKS, в той же убунте вполне доступен. А encfs вообще может подписывать зашифрованные данные, так что никакие модификации незамеченными не пройдут. (У него есть свои особенности — это не block-level шифрование, а file-level, но удобен очень — можно директорию-оригинал разместить в Dropbox, зашифрованные файлики с нечитаемыми именами будут синхронизироваться, а где стоит encfs можно прозрачно получать их в расшифрованном виде.)
+1
LUKS — контейнер. Шифрование в контейнере чаще всего как раз AES-CBC.
-2
Поправка: AES-CBC-ESSIV, последний увеличивает вероятность обнаружения описанной атаки.
-2
Уже давно AES-XTS-PLAIN по умолчанию. А выбрать его руками можно было с 2007 года.
+1
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...., но не сейчас.
0
xts по умолчанию в cryptsetup 1.6+ (в debian wheezy, например, 1.4.3; в centos6 — 1.2.0), но установщик убунты может по умолчанию предлагать xts при создании зашифрованного тома через него. Кто создаёт тома через cryptsetup должен осознавать, что означают различные параметры.
0
А теперь внимательно читаем 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 другие, не более.
0
Иии?.. Как это противоречит тому, что cryptsetup 1.6+ имеет aes-xts-plain64 по умолчанию при сборке (если иного не указано при запуске ./configure)?
0
Ещё раз. Медленно. Внимательно читаем.
Английским по белому написано: «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»».
-5
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.
+2
$ 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»
0
версия 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, то это вопрос к мейнтейнерам, почему они используют такие параметры сборки.+1
Вот в 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
0
В макоси используется XTS и для file vault и для криптованных дисков.
0
Подробно такая атака описана в другой статье, там же — практическая реализация для Ubuntu 12.04.И там же написано, что 12.10 использует xts по умолчанию.
+1
Спасибо, далек от информационной безопасности, про трюк с загрузчиком не знал. Хотя после того как все объяснено вроде очевидно.
На буке диск зашифрован на случай кражи в основном так что риск не велик но теперь знаю что риск есть.
На буке диск зашифрован на случай кражи в основном так что риск не велик но теперь знаю что риск есть.
+2
- Хранить флешку (SD) с установочником чистой системы и переключателем только для чтения «ON» и минимальным набором нужного софта без конфигов
- Грузится только с нее и работать только в ОЗУ
- иметь в ноуте самый мелкий SSD с бутафорской, но рабочей системой
Затем как было в одной статье, если попросили ноутбук, «выключаем» или отдаем уже выключенный. Пусть резвятся и ставят трояны. Затем, когда надо работать, пихаем флешку, ставим систему и работаем в ОЗУ.
Нужен ноут со с нежрущим процессором, пассивным охлаждением и хорошей батарейкой. Если пойти дальше — заменить экран на E-Ink, ну и «припаять внутрь», чтобы при потере питания встроенный LiIon таблетка затирала на нем данные (E-Ink же).
+1
Хорошее решение, но требует специфичной операционки (с флешки хорошо работает Fedora, а вот винда или OSX с флешки работают не то чтобы очень хорошо). Для большинства пользователей такой способ не подойдет?
0
А если запихнут троян в биос? Были же прецеденты
0
А есть хотя бы один «живой» дистрибутив с графической средой, в которой можно хоть как-то решать повседневные задачи, но в котором полностью исключена возможность автоматического (без участия пользователя) запуска недоверенных программ с HDD/SSD в процессе загрузки?
0
Это зависит от того, какие программы понимать как недоверенные.
Большинство дистрибутивов GNU/Linux реализуют функционал по ограничению запуска приложений и скриптов — см. SELinux. Более того, можно задать доступ каждому приложению к конкретным ресурсам и ни к каким другим.
Большинство дистрибутивов GNU/Linux реализуют функционал по ограничению запуска приложений и скриптов — см. SELinux. Более того, можно задать доступ каждому приложению к конкретным ресурсам и ни к каким другим.
0
Это зависит от того, какие программы понимать как недоверенные.
Любые, которые может разместить атакующий на накопителе компьютера пользователя. Вопрос был с подвохом, если что: в сообщении ранее речь шла о том, что можно обмануть атакующего, который имел возможность записать на накопитель компьютера любой свой бекдор, путем загрузки с USB-накопителя. Предполагается, что «живой» дистрибутив будет функционировать независимо от программ на HDD/SSD, с которым проводил манипуляции атакующий, однако это не так.
0
Большинство решений по шифрованию жесткого диска используют алгоритм AES в блочном режиме CBC.
Ну, естественно, если использовать совершенно не предназначенный для этого режим, вы получите проблемы с безопасностью. Снова встаёт вопрос качества ПО от Microsoft.
Нормальный и вменяемый LUKS, например, по умолчанию испольует специально разработанный для шифрования дисков режим XTS (с блочным шифром AES).
Хотя и в XTS есть проблемы, но по крайней мере проблема, когда злодей знает открытый текст, решена.
+1
А в каких мейнстрим дистрибутивах по умолчанию используется LUKS?
0
«По умолчанию» в популярных дистрибутивах никакое шифрование не используется. В убунте сделали какой-то интерфейс, но я сомневаюсь в его качестве.
В инсталляторе Debian (и Ubuntu, если использовать не этот красивый и бестолковый гуй, а debian-installer) LUKS можно настроить «из коробки», то есть, он там не по умолчанию, но опция есть прямо сразу.
Судя по документации, в Fedora то же самое, Anaconda (инсталлятор) умеет ставить на LUKS.
А вообще LUKS поддерживается в любом, и инструкции есть для всех дистрибутивов.
В инсталляторе Debian (и Ubuntu, если использовать не этот красивый и бестолковый гуй, а debian-installer) LUKS можно настроить «из коробки», то есть, он там не по умолчанию, но опция есть прямо сразу.
Судя по документации, в Fedora то же самое, Anaconda (инсталлятор) умеет ставить на LUKS.
А вообще LUKS поддерживается в любом, и инструкции есть для всех дистрибутивов.
0
При установке почти в любом. В инсталляторе при ручной разбивке диска создаёшь зашифрованный том, и всё.
0
Нормальный и вменяемый LUKS, например
… стал использовать XTS всего-то меньше трех лет назад. Тогда как битлокер в Vista/Win7 позволял использовать дополнительную защиту, решающую проблему. Так что не надо про качество.
0
+1
Стоит также сказать, что XTS, как стандарт опубликован только в декабре 2007.
0
Вчера была опубликована статья, в которой, не без помощи Microsoft, раскрываются интересные подробности о внутренностях BitLocker. Статья длинная и ее содержимое можно резюмировать как «в целом выглядит адекватно, явных уязвимостей вроде не видно».
Помнится, как-то решил поставить его на семерку — но так и не получилось настроить на авторизацию по паролю как в трукрипте и аналогах. Плюнул и поставил трукрипт.
Это же самый удобный и очевидный режим авторизации, из каких соображений его не добавили?
0
Он на самом деле есть, просто действительно включается не то чтобы просто :). Там нужно залезть в политики и вручную разрешить использовать пароль для ввода с клавиатуры.
Сделано так исходя из соображений безопасности: для низкоквалифицированных сотрудников крупных компаний проще носить флешку на брелке для ключей, чем запоминать пароль. И если сделать простой ввода пароля… Бумажки рядом с мониторами все видели? :)
Сделано так исходя из соображений безопасности: для низкоквалифицированных сотрудников крупных компаний проще носить флешку на брелке для ключей, чем запоминать пароль. И если сделать простой ввода пароля… Бумажки рядом с мониторами все видели? :)
+2
Когда вы запускаете компьютер с 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.» А у вас этот момент упущен.
+1
А много ли толку в защите от подмены загрузчика, если там диск зашифрован в режиме CBC, который уязвим к подмене данных на самом зашифрованном разделе в случае знания открытого текста, а его-то все знают — например, у всех есть одинаковый ntoskrnl.dll (или как он там называется)?
-1
1. На Vista/Win7 не уязвим (если правильно настроен).
2. Точность надо соблюдать в любом случае. :)
3. Ну и лично я считаю, что всегда полезно придерживаться правила «если девайс физически попал в руки врагу, он скомпрометирован».
2. Точность надо соблюдать в любом случае. :)
3. Ну и лично я считаю, что всегда полезно придерживаться правила «если девайс физически попал в руки врагу, он скомпрометирован».
+1
Поясните, какие именно средства делают Win7 неуязвимым к подмене каждого второго блока CBC?
0
Полагаю, это механизм windows file protection, который проверяет целостность системных файлов и, в случае их подмены, восстанавливает из shadow копии. К сожалению, для атаки можно подменять не только системные файлы, но и множество других — всякие autorun итд. Разработчики из соседнего отдела нашептывают что задача это нетривиальная, но само знание о возможности такой атаки ценно.
0
Насколько я понимаю, там добавлен дополнительный слой защиты (diffuser), который специально предназначен для противодействия таким атакам — css.csail.mit.edu/6.858/2012/readings/bitlocker.pdf
0
Так убрали ж диффузер в новых версиях?
0
Да. Потому я и пишу — 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 решает проблему.
0
«Пусть не решит он всех проблем...»
Это совершенно не отменяет того факта, что CBC для шифрования диска не подходит.
Полностью проблема оффлайновой модификации шифртекста не решается без использования MAC. А поскольку под них тоже требуется что-то зарезервировать, на хорошо-зашифрованном-диске места будет явно меньше, чем на незашифрованном, а заодно конверсия незашифрованного диска в зашифрованный «на лету» становится сложно реализуемой. Думаю, поэтому-то программы шифрования с MAC и не особенно популярны.
Это совершенно не отменяет того факта, что CBC для шифрования диска не подходит.
Полностью проблема оффлайновой модификации шифртекста не решается без использования MAC. А поскольку под них тоже требуется что-то зарезервировать, на хорошо-зашифрованном-диске места будет явно меньше, чем на незашифрованном, а заодно конверсия незашифрованного диска в зашифрованный «на лету» становится сложно реализуемой. Думаю, поэтому-то программы шифрования с MAC и не особенно популярны.
0
Спасибо большое, исправил!
0
в аэропорту солнечной Испании у вас на 10 минут попросили досмотреть ноутбук с зашифрованным жестким диском
Ну уж Вы загнули! В Европе весь досмотр сводится к просьбе открыть ноут, чтобы убедиться, что это не муляж для провоза контрабанды, и то не всегда. Да и по законодательству любой досмотр должен проводиться строго в присутствии владельца. Так что никаких «дайте на 10 минут» быть не может. Не говоря уж о том, чтобы подсадить какой-нибудь вирус…
Вот Израиль — более вероятный кандидат. Там теоретически и ноут могут попросить и вернуть его вам по винтикам, если заподозрят что-нибудь. Но вроде бы ни с кем не приключалось.
В Британии любая, даже самая совершенная система шифрования тупо скомпроментирована законодательством. Вас вежливо попросят ввести пароль или ключ для досмотра содержимого. При отказе или невозможности проделать оную операцию вас проводят в КПЗ для дальнейшего разбирательства.
В России также при пересечении границы могут потребовать средства хранения данных для досмотра. Хотя на счет обязательного предоставления ключа для расшифровки не уверен. Последний и единственный раз у меня проверяли дискеты лет этак N-дцать назад.
0
Средства обеспечения безопасности для личного пользования — они в первую очередь от любопытствующих, случайных утечек и воров. Если случилось постановление Английского суда выдать ключ шифрования — то это уже переходит в юридическю плоскость и выходит за рамки хабра :).
0
В Британии, тем не менее, не обязательно смогут что-то подменить, хотя и смогут прочитать.
Ключ, которым вы шифруете, не обязан совпадать с ключом, использующимся для проверки подписей. Ключ для расшифровки — вот, пожалуйста, читайте. А ключ для подписей они требовать по этому закону не могут.
Ключ, которым вы шифруете, не обязан совпадать с ключом, использующимся для проверки подписей. Ключ для расшифровки — вот, пожалуйста, читайте. А ключ для подписей они требовать по этому закону не могут.
+2
> Но вроде бы ни с кем не приключалось.
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
0
Хотел написать про Evil Maid, буткиты и Cold Boot-атаки еще года два назад, но руки так и не дошли пока.
В общем, если кому-то интересно, то напишу статью.
Bitlocker частично защищен от этой атаки — его загрузчик проверяет собственную целостность (конечно, ничто не мешает поменять и код проверки — но это намного труднее), OSX и популярные дистрибутивы Linux не имеют даже такой защит.Не совсем так. Во-первых, есть специальные скрипты, которые проверяют целостность всего во время загрузки ОС. Во-вторых, есть Secure Boot, который частично может использоваться и как средство защиты от Evil Maid (скажем, пароль на изменение конфигурации UEFI). Вы можете сгенерировать свои ключи, подписать ими загрузчик и ядро, и не позволить внедрить чужие ключи обычным паролем на изменение конфигурации. В-третьих, есть TPM, с использованием которого можно шифровать rootfs, подписав ключ шифрования LUKS TPM и PCR-регистрами, таким образом, rootfs не расшифруется, если изменили загрузчик, ядро, initramfs, или даже параметры, передаваемые ядру.
В общем, если кому-то интересно, то напишу статью.
+13
Правильно ли я понимаю, что если изменить один из блоков, воспользовавшись «уязвимостью» AES-CBC, то соседний с ним блок испортится?
+3
Интересно почитать, архивы (AES) тоже *открывали по наличию стандартных файлов внутри.
Не проще ли оставить важные данные дома, и через VPN (что по душе) подключаться по мере необходимости?
А при себе на таможню ничего зашифрованного не иметь и тем самым не привлекать внимание. Если интерес все же возникнет, то какую реализацию не используй, а показывать что внутри придется.
Но ведь надо придумать что то 99,9% рабочее.
Не проще ли оставить важные данные дома, и через VPN (что по душе) подключаться по мере необходимости?
А при себе на таможню ничего зашифрованного не иметь и тем самым не привлекать внимание. Если интерес все же возникнет, то какую реализацию не используй, а показывать что внутри придется.
Второй закон Шамира: криптографию не сломают, ее обойдут.
Но ведь надо придумать что то 99,9% рабочее.
0
Большинство решений по шифрованию жесткого диска используют алгоритм AES в блочном режиме CBC. А у этого алгоритма есть забавная особенность.
Неудачная фраза, которая может привести в возникновению некорректного мема (и судя по комментариям он уже зарождается). Можно подумать, что проблема в AES или в сочетании AES-CBC. На самом-то деле проблема исключительно в CBC и подобную атаку «через блок» можно организовать для любого блочного алгоритма шифрования.
+2
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атака «evil maid» на зашифрованный жесткий диск