id: Гость   вход   регистрация
текущее время 14:32 28/03/2024
Автор темы: Гость, тема открыта 21/12/2012 11:34 Печать
Категории: криптография, анонимность
https://www.pgpru.com/Форум/Офф-топик/НоваяПрограммаЭлкомсофтаВоруетКлючиПрограммBitLockerPGPИTrueCryptИзОперативки
создать
просмотр
ссылки

Новая программа «Элкомсофта» ворует ключи программ 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/


 
На страницу: 1, 2 След.
Комментарии
— Гость (21/12/2012 23:31)   <#>
Можно шифровать корень одной пассфразой, а каждый нужный /home/username — другой, своей пассфразой. При загрузке разумно вводить пассфразу только на корень, а дальше, уже залогинившись, подключать тех юзеров, чьи разделы нужны — как-то так я себе это представляю. А автоматически монтировать и подключать все разделы, да ещё и после ввода только одной пассфразы... — нет, это не для меня :)
— unknown (22/12/2012 00:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А кто сказал, что монтируются все разделы? А разделов не 1024, из них a — автомонтируются, b — по запросу, c — скрытых, d — висят на рейдах, e — на сетевых носителях, f на внешних, которые подключаются только при монтировании каких-то других и т.д. И из них не сделаны цепочки, петли, кольца, графы и деревья :)
— Гость (22/12/2012 00:27)   <#>
и дать гармонично существовать
хочется уточнить )) лени и беспечности?
— Гость (23/12/2012 14:54)   <#>
Волнует вопрос – если fireware отключен в биосе, а экран блокируется на время отсутствия, то кроме холодной перезагрузки опасаться нечего? Имеется в виду одноразовая попытка. Предварительная подготовка к атаке путём установки клавиатурных кейлогеров или скрытых видеокамер не рассматривается, т.к. относится к физической защите помещения.

Считывание ключей из памяти штатной утилитой позволяет организовывать в Linux иерархическое шифрование

Не могли бы развернуть мысль в плане практической реализации? В моём представлении: есть мастер-ключ, защищённый паролем и хранящийся в файле. Ключ для конкретного устройства получается расшифровкой мастер-ключа с добавленим в него искажения, зависящего от устройства. Например, исключающее ИЛИ (XOR) серийного номера устройства с мастер-ключом. Серийные номера удобны тем, что изображены на корпусе и поэтому их не нужно запоминать. Для каждого устройства получается свой ключ шифрования. С целью автоматизации действий создаётся скрипт, который извлекает ключ из памяти (dmsetup --showkeys), модифицирует в соответствии с серийным номером, создаёт виртуальное устройство /dev/mapper/name и монтирует его. Можно реализовать автомонтирование шифрованных устройств добавлением этого скрипта в правила udev. При таком подходе все устройства равноправны, и неясно как обеспечить их иерархию.
— unknown (23/12/2012 19:17)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В /lib/cryptsetup/scripts загляните. В частности в decrypt_derived. Можно целую статью написать, как эти хитрости использовать, да всё пока руки не доходят. Если любопытно, можете нагуглить материал по теме.
— Гость (23/12/2012 23:45)   <#>

Unknown ранее что-то писал про «иерархическое расшифровывание» в его стиле, но гуглится только /comment48104. Возможно, был ещё один подобный комент на эту тему.
— Гость (24/12/2012 20:41)   <#>
В целом понятно – для шифрования нижних в иерархии устройств генерируется новый ключ, а паролем случит ключ родительского устройства. Возможные недостатки:

1. Размножение ключей усложняет их сохранение в виде твёрдых копий (на бумаге). Если все без исключения уствойства шифруются, то должны существовать неэлектронные носители с информацией, достаточной для восстановления ключей. Описанная выше схема с использованием символов маркировки дисков более экономичная в этом плане – сохраняется только мастер-ключ (защищённый паролем) в текстовой кодировке (например base64), а частные ключи восстанавливаются с помощью информации на корпусах устройств.

2. Управление такой иерархией специфично для Дебиана. На моей системе нет скриптов /lib/cryptsetup/scripts, нет их и в tgz-архиве последней версии cryptsetup-1.5.1.

3. Не ясна практическая необходимость в создании иерархии. Возможно она имеет смысл в многопользовательской системе, а для одного пользователя – зачем? В принципе иерархию можно создать и в описанном выше способе, добавив необратимость при создании ключей для нижележащих устройств с помощью хеширования: HASH(key XOR serial-number). Хотя в силу неизвестных широкой публике ньюансов, хеш ключа может оказаться слабее ключа. Всё-таки ключ – это чистая энтропия, а хеш – применение некой математической функции, с не вполне очевидными последствиями для случайности. Но аналогочное можно сказать и о шифровании ключа тем же самым ключом, используемым при выходе из режима hibernation. Интуитивно понятно что такая нелинейность может создать почву для атак.
— unknown (25/12/2012 09:42, исправлен 25/12/2012 10:30)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Управление такой иерархией специфично для Дебиана. На моей системе нет скриптов /lib/cryptsetup/scripts

Это верно, но нет проблем внедрить. Хотя в другом дистре какой-нибудь шибко умный автосборщик рамдиска может всё попортить. Правда это скорее всего приведёт не к утечке, а к необходимости восстанавливаться вручную после неудачной загрузки.


Не ясна практическая необходимость в создании иерархии.

  1. Своп для гибернейта на другом (отличном от корневого) физическом разделе, чтобы к нему не вводить пароль при загрузке (ввели один раз пароль от корня и всё). Возможность быстрого перетирания текущего ключа в слоте свопа без прекращения его работы (!) на ключе в памяти до отключения компа (если гибернейт больше не нужен и нужно быстро очистить накопленные там данные).
  2. Обмен информацией на шифрованной флэшке между двумя доверенными компами Sneakernet. Серийник флэшки может считываться автоматически через udev (это для удобства её автоопределения в fstab/crypttab), а пароль на монтирование вводить ввобще не надо, если один из открытых на компе разделов совпадает с паролем для слота шифрованной флэшки. Если что-то не подойдёт и не сработает, флэшка просто не откроется, уязвимости и утечки здесь нет.

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


Этот метод не хуже и не лучше, он другой и даёт дополнительные фичи, не всегда возможно нужные.



Эта проблема является уязвимостью режима шифрования LRW и пока наиболее успешно решена в режиме шифрования XTS.

— Гость (25/12/2012 12:23)   <#>
wwwSneakernet.
пояснение
— unknown (25/12/2012 12:35, исправлен 25/12/2012 12:36)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вариант: пользователь знает пароль раздела на компе A, с помощью флэшки он переносит информацию на раздел компа B, где также знает пароль. Он может сделать так, что пароль к самой флэшке он сам при этом знать не будет (хотя и не сможет доказать это третьему лицу). А знание паролей к обеим компам без физического доступа к ним не даст расшифровать флэшку. И это всё прозрачно, не используя ключевые файлы.

— SATtva (25/12/2012 22:14, исправлен 25/12/2012 22:15)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

А жёлтая пресса, тем временем, жжот напалмом:


Российские разработчики расшифровали криптоконтейнеры BitLocker, PGP и TrueCrypt

Разработанный экспертами продукт под названием Elcomsoft Forensic Disk Decryptor позволяет снять защиту с криптоконтейнеров мгновенно. Специалистам компании Elcomsoft удалось взломать защиту криптоконтейнеров BitLocker, PGP и TrueCrypt. Всю информацию, которая хранится в зашифрованных томах данных, можно проанализировать посредством криминалистического анализа.
— Гость (26/12/2012 00:31)   <#>

Ага:
Все три криптоконтейнеры
Криптоконтейнера (проверочное: она моя) — это что-то типа капоэйры? Что тут взять с прикошмарских контор.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3