Управление сертификатами?

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

Но в линуксе с этим обстоит как-то не слишком радостно. Может быть в других дистрибутивах дела обстоят получше, не знаю. У меня все происходит примерно так:

Не знаю почему, но видимо в linux бытует такое мнение, что PGP работает на ключах. Хотя я считаю что инфраструктура шифрования базируется на сертификатах. Это конечно мелочи, но управление сертификатами в линуксе реализовано из рук вон плохо.

Для начала импорт сертификата. Сертификат с закрытым ключем хранится в контейнере pkcs12, gpgsm (утилита для манипулирования сертификатами) в этом формате воспринимает только ключи. Начинаем колдовать.

Сперва обеспечим автоматический запуск gpg-agent. Честно говоря, не знаю как правильно сделать это в kde. Хотя судя по всему здесь описан правильный рецепт (надо дописать себе скриптик для выгрузки). Но есть одна проблема. Иногда gpg-agent может ругаться со словами:

gpg-agent[17182]: can't connect to `/home/gor/.gnupg/S.gpg-agent': В соединении отказано
gpg-agent: нет gpg-agent доступого для данной сессии

Это решается путем добавления флага --use-standard-socket при вызове агента или добавлением опции use-standard-socket в файле конфигурации ~/.gnupg/gpg-agent.conf.

Импортируем закрытый ключ:

$ openssl pkcs12 -in keycert.p12 -out keycert.pem -nodes
$ openssl pkcs12 -in keycert.pem -export -out key.p12 -nocerts -nodes
$ gpgsm --call-protect-tool --p12-import --store key.p12

Непонятно почему, но извлечь ключ сразу из .p12 не получается. Зато получается извлеч сертификат.

$ openssl pkcs12 -in keycert.p12 -out certs.pem -nokeys
$ gpgsm --import certs.pem

Чтобы это все заработало необходимо иметь доверие к корневому сертификату. Списки доверенных сертификатов хранятся в ~/.gpg/trustlist.txt. Там должен быть указан fingerptint корневого сертификата и опциональный флаг. Можно поручить это дело gpg-agent'у, указав ему при запуске опцию --allow-mark-trusted, или allow-mark-trusted в файле ~/.gnupg/gpg-agent.conf.

Но это еще далеко не все. Мы можем попытаться указать сертификат S/MIME в kmail, но на попытку подписи получим сообщение - Ошибка шифрования. Чтобы узнать подробности необходимо включать протокол работы gpgsm. Это можно сделать через настройку kmail, правда я не совсем понимаю как работает socket в качестве файла протокола, я указал просто имя файла. Что касается debug-level, то можно использовать следующие значения: none, basic, advanced, expert, guru. И после включения протокола можно узнать, что для полного счастья gpgsm не хватает dirmngr, это демон хранения CRL (почему он не в зависимостях?).

# emerge dirmngr

После этого в kmail почти все работает. Кроме одного неприятного момента. В окнах pinentry все сообщения выводятся закорючками, хотя судя по логу кодировку она использует системную.

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

PS: Все манипуляции с сертификатами, по идее, призвана обеспечивать программа Kaleopatra. Не знаю в каком формате сертификаты ей нужны, но ни .p12, ни .pem она не воспринимает.

Полезные ссылки:
Mew's S/MIME Support
HOWTO KMail gpg-agent kde
запоминалка gnupg-пароля, используем gpg-agent

Блочные устройства linux, шифрование и не только...

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

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

Начать стоит с того, что cryptoloop устарел. Наверное 50% ссылок по данной теме ведут на описание cryptoloop. Причем устарел он уже несколько лет назад.

Актуальной технологией на сегодняшний день является device-mapper. Но 40% из оставшихся ссылок указывают на описание cryptsetup, который вполне позволит настроить шифрование, но наверное не более того, хотя утвеждать не буду. Для типичного использования она вполне подходит. Кроме того расширение luks позволяет хранить информацию о используемом шифровании раздела. По умолчанию никакия информация нигде не хранится, что чревато ошибками конфигурирования. стоит ошибиться в алгоритме шифрования или ввести некорректный ключ (да, информация о корректности ключа тоже нигде не хранится) и данные будут безвозвратно уничтожены.

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

Cryptsetup - это обертка над базовым механизмом, о котором и пойдет речь дальше. А базовый механизм выглядит следующим образом. В ядре существует подсистема "Device Mapper", она находится в "Device Drivers" ---> "Multiple devices driver support (RAID and LVM)". Для управления носителями сущствует пакет device-mapper, в который входит в частности утилита dmsetup. Смысл существования этой подсистемы состоит в том, что она создает блочные устройства, которые располагаются в /dev/mapper, на основании информации о целях. Причем одно устройство маппера может состоять из нескольких целевых устройств. Собственно так это мапперу и указывается. Дескать создаем линейную цель, которая займет в создаваемом девайсе сектора с 0 по 999, но сама располагается на /dev/sda со смещением в 300 секторов от начала диска.

Примерно аналогично задается и шифрованная цель. Или правильнее говорить источник? Но в терминологии DM это называется target. Только дополнительно задается алгоритм шифрования и устанавливаеся ключ. Поддерживаемые ядром алгоритмы шифрования можно посмотреть в /proc/crypto. Помимо собственных алгоритмов ядром поддерживаются некоторые режимы работы блочного шифра. ecb, cbc, pcbc. Название блочного шифра комбинируется из двух этих понятий (например aes-cbc). Кроме того для шифрованного раздела необходимо задать метод формирования вектора инициализации сектора. Инфрмацию об этих методах можно найти в исходниках (drivers/md/dm-crypt.c), вот они: plain, essiv, benbi, null. перечислять подробности не буду.

Теперь начну возмущаться, как программист, который пытался внести то, что нужно в очень узкое ложе device mapper. Хотя какой смысл возмущаться, любая открытая разработка следует каким-то своим целям, которые далеко не всегда соответствуют желаемому.

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

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

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

Конечно это все проектные проблемы. Для рядовых пользователей, желающих включить шифрование дисков - это все несущественно. Чувствую что тему не раскрыл, исправлюсь если что.

Cryptoloop in action...

Что касается LPC2468 (ранее упоминавшегося ARM), то мне удалось отыскать hsc0 патч для ядра 2.6.11.8, что позволило отделить зерна от плевел... То есть отделить изменения касающиеся непосредствено плат LPC от изменений hsc0. Теперь я могу наверное с минимумом напильника наложить архитектуру LPC на более свежее ядро... Но это будет уже в следующем году.

А пока вожусь с шифрованием. Реализовал шифрование по ГОСТ 28147-89 для ядра, там оказалось все достаточно грамотно сделано в этом плане. Режимы работы блочных шифров (правда только CBC и ECB) ядро реализует универсально. От модуля шифрования лишь требуется предоставить две функции по шифрованию и расшифрованию блока. Мне даже удалось без проблем заставить работать со всем этим cryptoloop девайс. Шифрует эта железяка конечно очень медленно... ни один алгоритм не разогнался до 100kib/s, будем искать железку помощнее (пока положили глаз на Intel PXA 806Mhz).

Но не смотря на все трудности основной режим проекта - проходное шифрование флешек уже работает. То есть флешка втыкается к LPC2468 в хостовый разъем, а сама LPC2468 втыкается в комп как девайс. И комп видит флешку, как живую (только медленную), при этом если флешку просто воткнуть в комп, то видно, что над ней кто-то жестоко поиздевался, сплошной urandom.

Не знаю как они собираются сделать проходное шифрование IDE, SATA. Но задачка будет интересная.