Новая программа «Элкомсофта» ворует ключи программ BitLocker, PGP и TrueCrypt из оперативки
Компания «Элкомсофт» выпустила программу Elcomsoft Forensic Disk Decryptor, которая предназначена для криминалистической экспертизы криптоконтейнеров BitLocker, PGP и TrueCrypt. Поддерживаются как фиксированные, так и портативные носители, включая PGP в режиме шифрования всего диска, а также съёмные диски, защищённые с помощью BitLocker To Go. С помощью Elcomsoft Forensic Disk Decryptor можно как полностью расшифровать содержимое защищённого тома, так и работать в реальном времени с подключением зашифрованных томов и расшифровкой выбранных данных «на лету».
Программа извлекает ключи шифрования тремя методами:
1. Из дампа оперативной памяти. Все ключи извлекаются единовременно, даже если в системе присутствуют более, чем один криптоконтейнер. Дамп оперативной памяти может быть создан с помощью соответствующих криминалистических продуктов, например, MoonSols Windows Memory Toolkit. Зашифрованные тома в момент снятия слепка должны быть подключены; в противном случае ключ расшифровки извлечь не удастся. Подробное описание этой технологии (и полный список коммерческих и бесплатных программ см. здесь.
2. Анализ файла гибернации (исследуемый компьютер выключен). Защищённые тома должны быть подключены перед выключением компьютера. Если криптоконтейнер был размонтирован перед созданием файла гибернации, извлечь из него ключи будет невозможно.
3. Атакой через порт FireWire, если у вас не хватает прав для снятия дампа памяти или запуска программ на анализируемом компьютере. Для проведения атаки через порт FireWire требуется дополнительный компьютер с установленным бесплатным продуктом (например, Inception). Такая атака даёт практически стопроцентный результат, но опять же, зашифрованные тома должны быть подключены в момент анализа.
http://www.xakep.ru/post/59849/
комментариев: 9796 документов: 488 редакций: 5664
Не могли бы развернуть мысль в плане практической реализации? В моём представлении: есть мастер-ключ, защищённый паролем и хранящийся в файле. Ключ для конкретного устройства получается расшифровкой мастер-ключа с добавленим в него искажения, зависящего от устройства. Например, исключающее ИЛИ (XOR) серийного номера устройства с мастер-ключом. Серийные номера удобны тем, что изображены на корпусе и поэтому их не нужно запоминать. Для каждого устройства получается свой ключ шифрования. С целью автоматизации действий создаётся скрипт, который извлекает ключ из памяти (dmsetup --showkeys), модифицирует в соответствии с серийным номером, создаёт виртуальное устройство /dev/mapper/name и монтирует его. Можно реализовать автомонтирование шифрованных устройств добавлением этого скрипта в правила udev. При таком подходе все устройства равноправны, и неясно как обеспечить их иерархию.
комментариев: 9796 документов: 488 редакций: 5664
Unknown ранее что-то писал про «иерархическое расшифровывание» в его стиле, но гуглится только /comment48104. Возможно, был ещё один подобный комент на эту тему.
1. Размножение ключей усложняет их сохранение в виде твёрдых копий (на бумаге). Если все без исключения уствойства шифруются, то должны существовать неэлектронные носители с информацией, достаточной для восстановления ключей. Описанная выше схема с использованием символов маркировки дисков более экономичная в этом плане – сохраняется только мастер-ключ (защищённый паролем) в текстовой кодировке (например base64), а частные ключи восстанавливаются с помощью информации на корпусах устройств.
2. Управление такой иерархией специфично для Дебиана. На моей системе нет скриптов /lib/cryptsetup/scripts, нет их и в tgz-архиве последней версии cryptsetup-1.5.1.
3. Не ясна практическая необходимость в создании иерархии. Возможно она имеет смысл в многопользовательской системе, а для одного пользователя – зачем? В принципе иерархию можно создать и в описанном выше способе, добавив необратимость при создании ключей для нижележащих устройств с помощью хеширования: HASH(key XOR serial-number). Хотя в силу неизвестных широкой публике ньюансов, хеш ключа может оказаться слабее ключа. Всё-таки ключ – это чистая энтропия, а хеш – применение некой математической функции, с не вполне очевидными последствиями для случайности. Но аналогочное можно сказать и о шифровании ключа тем же самым ключом, используемым при выходе из режима hibernation. Интуитивно понятно что такая нелинейность может создать почву для атак.
комментариев: 9796 документов: 488 редакций: 5664
Это верно, но нет проблем внедрить. Хотя в другом дистре какой-нибудь шибко умный автосборщик рамдиска может всё попортить. Правда это скорее всего приведёт не к утечке, а к необходимости восстанавливаться вручную после неудачной загрузки.
В отличие от предложенных вами методов при этом не требуется сохранения никаких ключевых файлов на файловой системе носителя, которые трудно удалять, в отличие от простого и надёжного затирания заголовков LUKS-слотов при необходимости.
Этот метод не хуже и не лучше, он другой и даёт дополнительные фичи, не всегда возможно нужные.
Эта проблема является уязвимостью режима шифрования LRW и пока наиболее успешно решена в режиме шифрования XTS.
комментариев: 9796 документов: 488 редакций: 5664
Вариант: пользователь знает пароль раздела на компе A, с помощью флэшки он переносит информацию на раздел компа B, где также знает пароль. Он может сделать так, что пароль к самой флэшке он сам при этом знать не будет (хотя и не сможет доказать это третьему лицу). А знание паролей к обеим компам без физического доступа к ним не даст расшифровать флэшку. И это всё прозрачно, не используя ключевые файлы.
комментариев: 11558 документов: 1036 редакций: 4118
А жёлтая пресса, тем временем, жжот напалмом:
Российские разработчики расшифровали криптоконтейнеры BitLocker, PGP и TrueCrypt
Ага: Криптоконтейнера (проверочное: она моя) — это что-то типа капоэйры? Что тут взять с прикошмарских контор.