Атака «evil maid» на зашифрованный жесткий диск / forpes.ru

Главная
Атака «evil maid» на зашифрованный жесткий диск

Атака «evil maid» на зашифрованный жесткий диск +59

08.06.2015 07:01

yaroslavb 70 27545 Источник

Вчера была опубликована статья, в которой, не без помощи Microsoft, раскрываются интересные подробности о внутренностях BitLocker. Статья длинная и ее содержимое можно резюмировать как «в целом выглядит адекватно, явных уязвимостей вроде не видно». Зато по ссылкам много интересной информации о разных атаках на зашифрованный жесткий диск. Полагаю, хабражителям будет интересно краткое изложение атаки с романтичным названием «evil maid» и ее логическое продолжение. Надежно ли защищена ваша деловая переписка от молодых любопытных таможенников, если в аэропорту солнечной Испании у вас на 10 минут попросили досмотреть ноутбук с зашифрованным жестким диском?

Казалось бы, если используется адекватный алгоритм шифрования и злоумышленник или просто любопытствующий не знает вашего пароля — то деловая переписка в полной безопасности. Так ли это?

Не совсем. Шифрование реализовывает операционная система. Когда вы запускаете компьютер с Linux, Windows или OSX, вначале стартует некий код операционной системы, который запрашивает у вас фразу-пароль от зашифрованного жесткого диска, после чего использует ее для расшифровки жесткого диска в реальном времени (или только home dir, если используется шифрование по умолчанию в OSX). Атака «evil maid» заключается в том, что backdoor, отсылающий злоумышленнику всю необходимую информацию, встраивается в запрашивающий пароль код. Который не зашифрован, потому что должен выполниться при старте компьютера до того, как пользователь введет фразу-пароль. Вам вернули ноутбук, вы посмеялись над недалекими проверяльщиками, включили его, ввели пароль, загрузили операционку — и все, backdoor уже на вашем компьютере. Bitlocker частично защищен от этой атаки — его загрузчик проверяет собственную целостность (конечно, ничто не мешает поменять и код проверки — но это намного труднее), OSX и популярные дистрибутивы Linux не имеют даже такой защит.

Параноики от безопасности знают о таком подходе и в случае подозрений что кто-то модифицировал диск компьютера загружаются с usb и перезаписывают часть операционной системы, отвечающей за первоначальную загрузку и ввод пароля. Или используют usb ключ вместо ввода фразы-пароля. Или загружаются с usb. Или любой другой способ. Но достаточно ли этого?

Оказывается, нет. Большинство решений по шифрованию жесткого диска используют алгоритм AES в блочном режиме CBC. А у блочного режима шифрования есть забавная особенность. Если злоумышленник знает содержимое зашифрованного файла на жестком диске, но не знает ключа, то он может модифицировать зашифрованные данные таким образом, что после расшифровки получится нужное ему содержимое. Неожиданно, да? Можно не трогать загрузчик. Зная версию операционной системы и расположение ее стандартных фалов на диске можно внедрить backdoor в системные файлы, просто перезаписав часть зашифрованных блоков. Подробно такая атака описана в другой статье, там же — практическая реализация для Ubuntu 12.04 (начиная с 12.10 по умолчанию используется XTS, что защищает операционку от данной атаки).

Начиная с OSX Lion (10.7) средство шифрования по умолчанию изменено на «File Vault 2», в котором вместо AES-CBC используется XTS-AESW, защищенное от такой атаки.

Безусловно, такие атаки известны любому читателю, знакомому с основами информационной безопасности. Всем остальным, надеюсь, информация об этих двух атаках будет, как минимум, любопытна. В качестве иллюстрации использовалась работа вот этого художника.

Комментарии (70)

Scratch
08.06.2015 10:20
#8451935
+6
Ну, AES-CBC уже на самом деле редкость для нормальных программ, везде уже XTS/GCM используется. А вот встраивание бекдоров в бутлоадер\биос, пока комп не у вас, это да, страшновато.
1. yaroslavb Автор
  08.06.2015 10:38
  #8451971
  Для программ — да. А для встроенных в операционку средств? Насколько я понял из статей, Bitlocker использует AES-CBC. Более того, средства для шифрования по умолчанию в Ubuntu тоже используют AES-CBC. А где используется XTS/GCM?
  1. Scratch
    08.06.2015 10:52
    #8451989
    XTS — Трукрипт, из встроенных- ZFS использует GCM
    
    yaroslavb Автор
    08.06.2015 11:04
    #8452017
    Любопытно. А какие-нить мейнстримовые дистрибутивы по умолчанию ставят ZFS? Насколько я понимаю экосистему, сейчас все по умолчанию на ext4 сидят? Или нет?
    
    robert_ayrapetyan
    08.06.2015 15:01
    #8452399
    FreeBSD скоро будет на ZFS скорей всего (по карайней мере, в 10-ке root on ZFS уже поддерживается инсталлятором)
  1. merlin-vrn
    08.06.2015 11:00
    #8452007
    +1
    LUKS, в той же убунте вполне доступен. А encfs вообще может подписывать зашифрованные данные, так что никакие модификации незамеченными не пройдут. (У него есть свои особенности — это не block-level шифрование, а file-level, но удобен очень — можно директорию-оригинал разместить в Dropbox, зашифрованные файлики с нечитаемыми именами будут синхронизироваться, а где стоит encfs можно прозрачно получать их в расшифрованном виде.)
    
    grumbler66rus
    09.06.2015 18:52
    #8454557
    -2
    LUKS — контейнер. Шифрование в контейнере чаще всего как раз AES-CBC.
    
    grumbler66rus
    09.06.2015 19:17
    #8454607
    -2
    Поправка: AES-CBC-ESSIV, последний увеличивает вероятность обнаружения описанной атаки.
    
    merlin-vrn
    10.06.2015 09:14
    #8455167
    +1
    Уже давно AES-XTS-PLAIN по умолчанию. А выбрать его руками можно было с 2007 года.
    
    grumbler66rus
    10.06.2015 21:19
    #8456173
    man cryptsetup сообщает иное:
    
    --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...., но не сейчас.
    
    grossws
    10.06.2015 21:32
    #8456213
    xts по умолчанию в cryptsetup 1.6+ (в debian wheezy, например, 1.4.3; в centos6 — 1.2.0), но установщик убунты может по умолчанию предлагать xts при создании зашифрованного тома через него. Кто создаёт тома через cryptsetup должен осознавать, что означают различные параметры.
    
    grumbler66rus
    10.06.2015 21:40
    #8456223
    А теперь внимательно читаем man 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 другие, не более.
    
    grossws
    10.06.2015 23:19
    #8456371
    Иии?.. Как это противоречит тому, что cryptsetup 1.6+ имеет aes-xts-plain64 по умолчанию при сборке (если иного не указано при запуске ./configure)?
    
    grumbler66rus
    11.06.2015 10:13
    #8456715
    -5
    Ещё раз. Медленно. Внимательно читаем.
    Английским по белому написано: «The current default in the distributed sources is «aes-cbc-essiv:sha256»»
    Если не умеешь читать английский текст и не умеешь пользоваться переводчиком, вот перевод:
    «Текущее умолчание в исходниках — «aes-cbc-essiv:sha256»».
    
    grossws
    11.06.2015 13:01
    #8456955
    +2
    1. Не хамите.
    
    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.
    
    grumbler66rus
    11.06.2015 20:49
    #8457731
    $ 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»
    
    grossws
    12.06.2015 01:47
    #8457975
    +1
    версия 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, то это вопрос к мейнтейнерам, почему они используют такие параметры сборки.
    
    grumbler66rus
    10.06.2015 21:35
    #8456215
    Вот в 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
  1. isden
    08.06.2015 11:23
    #8452071
    В макоси используется XTS и для file vault и для криптованных дисков.
    
    yaroslavb Автор
    08.06.2015 11:29
    #8452087
    Спасибо, дописал! Оказывается, начиная с 10.7 они сделали File Vault 2, в котором отказались от CBC. Полезная штука Хабр :).
    
    isden
    08.06.2015 11:31
    #8452095
    +1
    Еще в FileVault 2 используется full disk encryption, а не только домик.
  1. grossws
    08.06.2015 13:09
    #8452227
    +1
    Подробно такая атака описана в другой статье, там же — практическая реализация для Ubuntu 12.04.
    И там же написано, что 12.10 использует xts по умолчанию.
    
    yaroslavb Автор
    08.06.2015 13:17
    #8452249
    О, это хорошие новости! Дописал, спасибо!

Semenych
08.06.2015 10:21
#8451939
+2
Спасибо, далек от информационной безопасности, про трюк с загрузчиком не знал. Хотя после того как все объяснено вроде очевидно.

На буке диск зашифрован на случай кражи в основном так что риск не велик но теперь знаю что риск есть.

nikitasius
08.06.2015 10:47
#8451981
+1
1. Хранить флешку (SD) с установочником чистой системы и переключателем только для чтения «ON» и минимальным набором нужного софта без конфигов
2. Грузится только с нее и работать только в ОЗУ
3. иметь в ноуте самый мелкий SSD с бутафорской, но рабочей системой
Затем как было в одной статье, если попросили ноутбук, «выключаем» или отдаем уже выключенный. Пусть резвятся и ставят трояны. Затем, когда надо работать, пихаем флешку, ставим систему и работаем в ОЗУ.
Нужен ноут со с нежрущим процессором, пассивным охлаждением и хорошей батарейкой. Если пойти дальше — заменить экран на E-Ink, ну и «припаять внутрь», чтобы при потере питания встроенный LiIon таблетка затирала на нем данные (E-Ink же).
1. yaroslavb Автор
  08.06.2015 10:49
  #8451985
  Хорошее решение, но требует специфичной операционки (с флешки хорошо работает Fedora, а вот винда или OSX с флешки работают не то чтобы очень хорошо). Для большинства пользователей такой способ не подойдет?
1. Scratch
  08.06.2015 10:53
  #8451991
  А если запихнут троян в биос? Были же прецеденты
  1. achekalin
    08.06.2015 13:28
    #8452265
    +2
    Ну при таких ставках по поводу данных терморектальный анализ дает свои плоды, не зависящие напрямую от разрядности и типа шифра.
1. msuhanov
  08.06.2015 17:38
  #8452699
  А есть хотя бы один «живой» дистрибутив с графической средой, в которой можно хоть как-то решать повседневные задачи, но в котором полностью исключена возможность автоматического (без участия пользователя) запуска недоверенных программ с HDD/SSD в процессе загрузки?
  1. grumbler66rus
    09.06.2015 19:02
    #8454575
    Это зависит от того, какие программы понимать как недоверенные.
    Большинство дистрибутивов GNU/Linux реализуют функционал по ограничению запуска приложений и скриптов — см. SELinux. Более того, можно задать доступ каждому приложению к конкретным ресурсам и ни к каким другим.
    
    msuhanov
    09.06.2015 19:25
    #8454623
    Это зависит от того, какие программы понимать как недоверенные.
    
    Любые, которые может разместить атакующий на накопителе компьютера пользователя. Вопрос был с подвохом, если что: в сообщении ранее речь шла о том, что можно обмануть атакующего, который имел возможность записать на накопитель компьютера любой свой бекдор, путем загрузки с USB-накопителя. Предполагается, что «живой» дистрибутив будет функционировать независимо от программ на HDD/SSD, с которым проводил манипуляции атакующий, однако это не так.
    
    grumbler66rus
    10.06.2015 21:45
    #8456231
    SElinux позволяет сделать такое, если соответствующие настройки добавить в initrd. Только это муторно и я не видел, чтобы кто-то заморочился.
    
    msuhanov
    11.06.2015 12:49
    #8456919
    Даже от программы, запущенной с привилегиями суперпользователя, защитит? И даже от выполнения недоверенного кода загрузчиком спасет?
    
    merlin-vrn
    11.06.2015 13:11
    #8456983
    +1
    Да. Нет.

merlin-vrn
08.06.2015 10:57
#8451995
+1
Большинство решений по шифрованию жесткого диска используют алгоритм AES в блочном режиме CBC.

Ну, естественно, если использовать совершенно не предназначенный для этого режим, вы получите проблемы с безопасностью. Снова встаёт вопрос качества ПО от Microsoft.

Нормальный и вменяемый LUKS, например, по умолчанию испольует специально разработанный для шифрования дисков режим XTS (с блочным шифром AES).

Хотя и в XTS есть проблемы, но по крайней мере проблема, когда злодей знает открытый текст, решена.
1. yaroslavb Автор
  08.06.2015 11:06
  #8452027
  А в каких мейнстрим дистрибутивах по умолчанию используется LUKS?
  1. merlin-vrn
    08.06.2015 11:14
    #8452039
    «По умолчанию» в популярных дистрибутивах никакое шифрование не используется. В убунте сделали какой-то интерфейс, но я сомневаюсь в его качестве.
    
    В инсталляторе Debian (и Ubuntu, если использовать не этот красивый и бестолковый гуй, а debian-installer) LUKS можно настроить «из коробки», то есть, он там не по умолчанию, но опция есть прямо сразу.
    
    Судя по документации, в Fedora то же самое, Anaconda (инсталлятор) умеет ставить на LUKS.
    
    А вообще LUKS поддерживается в любом, и инструкции есть для всех дистрибутивов.
  1. grumbler66rus
    09.06.2015 19:04
    #8454583
    При установке почти в любом. В инсталляторе при ручной разбивке диска создаёшь зашифрованный том, и всё.
1. ildarz
  08.06.2015 11:24
  #8452073
  Нормальный и вменяемый LUKS, например
  
  … стал использовать XTS всего-то меньше трех лет назад. Тогда как битлокер в Vista/Win7 позволял использовать дополнительную защиту, решающую проблему. Так что не надо про качество.
  1. merlin-vrn
    08.06.2015 11:33
    #8452103
    +1
    Ну, поддержка XTS появилась в 2.6.24, это 2007 год. CBC тянули для обратной совместимости.
    
    grossws
    08.06.2015 13:12
    #8452235
    Стоит также сказать, что XTS, как стандарт опубликован только в декабре 2007.
    
    merlin-vrn
    08.06.2015 13:40
    #8452279
    То есть, в ядро его включили ДО официального утверждения стандарта. (Код в коммите по ссылке выше датирован сентябрём, включен в дерево Линуса в октябре.)
    
    grossws
    08.06.2015 13:51
    #8452301
    Ага, но стандартизирующие организации типа IEEE, IETF, NIST никогда не славились слишком быстрой работой

veam
08.06.2015 11:09
#8452031
Вчера была опубликована статья, в которой, не без помощи Microsoft, раскрываются интересные подробности о внутренностях BitLocker. Статья длинная и ее содержимое можно резюмировать как «в целом выглядит адекватно, явных уязвимостей вроде не видно».

Помнится, как-то решил поставить его на семерку — но так и не получилось настроить на авторизацию по паролю как в трукрипте и аналогах. Плюнул и поставил трукрипт.
Это же самый удобный и очевидный режим авторизации, из каких соображений его не добавили?
1. yaroslavb Автор
  08.06.2015 11:20
  #8452061
  +2
  Он на самом деле есть, просто действительно включается не то чтобы просто :). Там нужно залезть в политики и вручную разрешить использовать пароль для ввода с клавиатуры.
  
  Сделано так исходя из соображений безопасности: для низкоквалифицированных сотрудников крупных компаний проще носить флешку на брелке для ключей, чем запоминать пароль. И если сделать простой ввода пароля… Бумажки рядом с мониторами все видели? :)

ildarz
08.06.2015 11:10
#8452033
+1
Когда вы запускаете компьютер с 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. merlin-vrn
  08.06.2015 11:19
  #8452057
  -1
  А много ли толку в защите от подмены загрузчика, если там диск зашифрован в режиме CBC, который уязвим к подмене данных на самом зашифрованном разделе в случае знания открытого текста, а его-то все знают — например, у всех есть одинаковый ntoskrnl.dll (или как он там называется)?
  1. ildarz
    08.06.2015 11:27
    #8452081
    +1
    1. На Vista/Win7 не уязвим (если правильно настроен).
    2. Точность надо соблюдать в любом случае. :)
    3. Ну и лично я считаю, что всегда полезно придерживаться правила «если девайс физически попал в руки врагу, он скомпрометирован».
    
    merlin-vrn
    08.06.2015 13:46
    #8452287
    Поясните, какие именно средства делают Win7 неуязвимым к подмене каждого второго блока CBC?
    
    yaroslavb Автор
    08.06.2015 13:53
    #8452305
    Полагаю, это механизм windows file protection, который проверяет целостность системных файлов и, в случае их подмены, восстанавливает из shadow копии. К сожалению, для атаки можно подменять не только системные файлы, но и множество других — всякие autorun итд. Разработчики из соседнего отдела нашептывают что задача это нетривиальная, но само знание о возможности такой атаки ценно.
    
    ildarz
    08.06.2015 14:43
    #8452365
    Насколько я понимаю, там добавлен дополнительный слой защиты (diffuser), который специально предназначен для противодействия таким атакам — css.csail.mit.edu/6.858/2012/readings/bitlocker.pdf
    
    yaroslavb Автор
    08.06.2015 14:49
    #8452375
    Так убрали ж диффузер в новых версиях?
    
    ildarz
    08.06.2015 15:00
    #8452395
    Да. Потому я и пишу — Vista/Win7. :)
    
    Но вот ещё занятный момент, к вопросу, почему MS не стали имплементировать XTS — csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_comments.pdf
    
    В общем, похоже, что в MS попросту не считают, что XTS решает проблему.
    
    merlin-vrn
    08.06.2015 15:31
    #8452433
    «Пусть не решит он всех проблем...»
    
    Это совершенно не отменяет того факта, что CBC для шифрования диска не подходит.
    
    Полностью проблема оффлайновой модификации шифртекста не решается без использования MAC. А поскольку под них тоже требуется что-то зарезервировать, на хорошо-зашифрованном-диске места будет явно меньше, чем на незашифрованном, а заодно конверсия незашифрованного диска в зашифрованный «на лету» становится сложно реализуемой. Думаю, поэтому-то программы шифрования с MAC и не особенно популярны.
1. yaroslavb Автор
  08.06.2015 11:24
  #8452075
  Спасибо большое, исправил!

Throwable
08.06.2015 12:08
#8452155
в аэропорту солнечной Испании у вас на 10 минут попросили досмотреть ноутбук с зашифрованным жестким диском

Ну уж Вы загнули! В Европе весь досмотр сводится к просьбе открыть ноут, чтобы убедиться, что это не муляж для провоза контрабанды, и то не всегда. Да и по законодательству любой досмотр должен проводиться строго в присутствии владельца. Так что никаких «дайте на 10 минут» быть не может. Не говоря уж о том, чтобы подсадить какой-нибудь вирус…

Вот Израиль — более вероятный кандидат. Там теоретически и ноут могут попросить и вернуть его вам по винтикам, если заподозрят что-нибудь. Но вроде бы ни с кем не приключалось.

В Британии любая, даже самая совершенная система шифрования тупо скомпроментирована законодательством. Вас вежливо попросят ввести пароль или ключ для досмотра содержимого. При отказе или невозможности проделать оную операцию вас проводят в КПЗ для дальнейшего разбирательства.

В России также при пересечении границы могут потребовать средства хранения данных для досмотра. Хотя на счет обязательного предоставления ключа для расшифровки не уверен. Последний и единственный раз у меня проверяли дискеты лет этак N-дцать назад.
1. yaroslavb Автор
  08.06.2015 12:18
  #8452167
  Средства обеспечения безопасности для личного пользования — они в первую очередь от любопытствующих, случайных утечек и воров. Если случилось постановление Английского суда выдать ключ шифрования — то это уже переходит в юридическю плоскость и выходит за рамки хабра :).
1. merlin-vrn
  08.06.2015 13:43
  #8452283
  +2
  В Британии, тем не менее, не обязательно смогут что-то подменить, хотя и смогут прочитать.
  
  Ключ, которым вы шифруете, не обязан совпадать с ключом, использующимся для проверки подписей. Ключ для расшифровки — вот, пожалуйста, читайте. А ключ для подписей они требовать по этому закону не могут.
1. ascending
  12.06.2015 18:20
  #8458685
  > Но вроде бы ни с кем не приключалось.
  lilyasussman.com/2009/11/30/im-sorry-but-we-blew-up-your-laptop-welcome-to-israel
  1. mtp
    17.06.2015 00:19
    #8464673
    -1
    Так это ж макбук. Конечно, им было сложно удержаться, чтобы не расстрелять его :-)

ValdikSS
08.06.2015 12:23
#8452173
+13
Хотел написать про Evil Maid, буткиты и Cold Boot-атаки еще года два назад, но руки так и не дошли пока.

Bitlocker частично защищен от этой атаки — его загрузчик проверяет собственную целостность (конечно, ничто не мешает поменять и код проверки — но это намного труднее), OSX и популярные дистрибутивы Linux не имеют даже такой защит.
Не совсем так. Во-первых, есть специальные скрипты, которые проверяют целостность всего во время загрузки ОС. Во-вторых, есть Secure Boot, который частично может использоваться и как средство защиты от Evil Maid (скажем, пароль на изменение конфигурации UEFI). Вы можете сгенерировать свои ключи, подписать ими загрузчик и ядро, и не позволить внедрить чужие ключи обычным паролем на изменение конфигурации. В-третьих, есть TPM, с использованием которого можно шифровать rootfs, подписав ключ шифрования LUKS TPM и PCR-регистрами, таким образом, rootfs не расшифруется, если изменили загрузчик, ядро, initramfs, или даже параметры, передаваемые ядру.

В общем, если кому-то интересно, то напишу статью.
1. Envek
  08.06.2015 13:14
  #8452239
  +1
  Напишите — важно знать, как обезопасить себя полностью.

mayorovp
08.06.2015 13:14
#8452241
+3
Правильно ли я понимаю, что если изменить один из блоков, воспользовавшись «уязвимостью» AES-CBC, то соседний с ним блок испортится?
1. grossws
  08.06.2015 13:16
  #8452245
  +2
  Да, придётся портить через 1, вставляя jmp в конец каждого.
1. amarao
  08.06.2015 19:22
  #8452887
  В совеременном коде много вещей, которые могут фейлиться и не мешать большей части функционала (мягкая деградация). Так что это может быть не проблемой.

Dywar
08.06.2015 21:14
#8453029
Интересно почитать, архивы (AES) тоже *открывали по наличию стандартных файлов внутри.
Не проще ли оставить важные данные дома, и через VPN (что по душе) подключаться по мере необходимости?
А при себе на таможню ничего зашифрованного не иметь и тем самым не привлекать внимание. Если интерес все же возникнет, то какую реализацию не используй, а показывать что внутри придется.

Второй закон Шамира: криптографию не сломают, ее обойдут.

Но ведь надо придумать что то 99,9% рабочее.
1. yaroslavb Автор
  08.06.2015 21:16
  #8453033
  Интерес представляет именно ассортимент обходных путей. Способов защиты есть множество. Но сами факты того, что можно подменять загрузчик или заифрованные блоки мне показался любопытным и достойным внимания. Больше знаешь — крепче спишь :).

KonstantinSoloviov
09.06.2015 15:09
#8454207
+2
Большинство решений по шифрованию жесткого диска используют алгоритм AES в блочном режиме CBC. А у этого алгоритма есть забавная особенность.

Неудачная фраза, которая может привести в возникновению некорректного мема (и судя по комментариям он уже зарождается). Можно подумать, что проблема в AES или в сочетании AES-CBC. На самом-то деле проблема исключительно в CBC и подобную атаку «через блок» можно организовать для любого блочного алгоритма шифрования.
1. yaroslavb Автор
  09.06.2015 15:46
  #8454267
  Разумно. Переписал.

m0Ray
13.06.2015 02:59
#8459071
+1
Я бы для КДПВ выбрал другую картинку:

Слабонервным не смотреть

Атака «evil maid» на зашифрованный жесткий диск +59

Комментарии (70)

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор

yaroslavb Автор