OpenPGP crypto key

Он решает ровно эту задачу. GnuPG и PGP поддерживают хранение закрытых ключей на PKCS#11-совместимых смарт-картах.

Токенов и так существует дофига (при том, что их безопасность — довольно-таки условная штука), а интерфейсов для работы с ключом из-под другой ОС или другого юзера в той же ОС нет. Лучше бы вы их сделали. Нужно, чтоб работа с приватным ключом велась под другой ОС, доступной по сети (допустим, на каком-то порту крутится демон). Клиент мог бы предоставлять демону данные на шифрование, расшифрование и подпись, но не мог бы заставить его выдать сам приватный ключ. И надо ещё интегрировать поддержку этого дела в тот софт, что завязан на PGP (mail-клиенты, jabber), чтоб прозрачно всё работало.

Если в новогодние каникулы не возникнет срочной работы, сделаю такую штуку. Единственно, поддерживать она будет только gpg, но не gpgme.

И это тоже сделаете? :-)

Если приложение использует обычный командный интерфейс gpg вместо линковки с gpgme, всё должно работать из коробки.

Решение видится следующим. Клиент-серверное приложение на питоне, используется простейший сетевой протокол а-ля telnet (никакого канального шифрования, его пользователь может навесить сам с помощью ssh-туннеля). Клиент, которым заменяется бинарник gpg, принимает набор команд и возможный ввод с stdin и без изменений шлёт серверу. Сервер отфильтровывает небезопасные команды (типа --export-secret-keys и таких, которые модифицируют связку, хотя скорее всего там будет настраиваемый белый список) и передаёт их локальному gpg. Полученный результат повторно фильтруется на предмет PRIVATE KEY BLOCK и возвращается клиенту. Клиент выводит данные.

Спасибо, понятно.

А если я ему передам на шифрование какой-нибудь третий приватный ключ, он его зашифрует? Или если слова «PRIVATE KEY BLOCK» будут в тексте, который надо будет зашифровать или подписать, он это сделает?

... к примеру, делаю запрос сделать --clearsign-подпись какого-нибудь приватного ключа.

Если какие-то внешне валидные штуки вдруг будут запрещены, в некоторых автоматических протоколах (типа tkabber XMPP) другая сторона потенциально сможет отличать обычных юзеров gpg от заSATtva'енных ⇒ брешь в анонимности.

<irony> Ой, и правда, если в jabber-клиенте дыра, и он почему-то не сливает закрытый ключ противнику, — это та ещё деанонимизация. </irony> Лол, а Вы хотели и рыбку съесть, и сковородку не запачкать? Но вообще под запрет должны попасть только реально небезопасные действия, которые программы-пользователи gpg и так не должны выполнять. Я даже пока не уверен, нужно ли в действительности отфильтровывать PRIVATE KEY BLOCK — это скорее перестраховка (тем более, что вывод может быть запрошен без --armor, а разбирать бинарный формат у меня нет никакого желания).

И я к тому, что перестраховка в некоторых случаях может дать тривиальный различитель. Пример с tkabber плохой, но, допустим, у нас есть некоторое приложение, работающее с сетью в сколь-нибудь автоматическом режиме. Сторона потенциального противника может добиться, чтобы я ему что-то подписал. Если вдруг оказывается, что мой клиент отправляет противнику все обычные сообщения, а после вставки в них определённой строки уже не отправляет, противник понимает, что моя версия gpg необычная.

К примеру, в почтовом письме абонент укажет где-то слова PRIVATE KEY BLOCK, а я должен буду их процитировать при ответе на письмо, подписать и отправить. Там, конечно, неавтоматически делается (поэтому пример тоже плохой), но смысл примерно в этом. Я клоню к тому, что стоит ли такое делать (перестраховку), если не знать всех подводных камней, где, кем и как такая обвязка может использоваться. Например, перестраховку можно сделать опциональной и отключаемой.

gpg не предназначен для анонимности путём сокрытия версий. Даже если там есть --no-emit-version, то я бы этому не доверял, у разработчиков стойкая неразличимость, скорее всего, не в приоритете.

Гость, я так понимаю, говорит о том, что если на стандартный ввод gpg возвращает нестандартный вывод (который может быть доступен противнику), противник может заключить, что пользователь использует gpg в нестандартном окружении. Получается достаточно уникальный профиль, снижающий анонимность до псевдонимности.

Да, или никакого.


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

Небольшой status report. Работаю над программой, осталось не так много. Увы, как бы мне того ни хотелось, полностью выдержать принцип KISS не удалось из-за поддержки обработки файлов — это потянуло за собой заметное усложнение кода. Плюс потребовалось более тонко разбирать аргументы командной строки, чтобы не сделать сервер уязвимым к раскрытию информации: в тривиальном случае клиент мог бы передать серверу путь к файлу в его (сервера) файловой системе, тот скормил бы его GPG и вернул клиенту.

Хорошо, будем посмотреть. Результат будет в виде чего? Питон-скрипт? Deb-пакет? Gentoo-ebild?