OpenPGP crypto key

Скрипты и документация.

Раньше как-то не придавал значение такой штуке, но тут она, конечно же, всплыла во всей красе. Изначально была надежда, что если не вайтлистить опции типа --import, то связка будет фактически только для чтения. Хрен бы там! GPG настолько умён, что читает мысли пользователя парсит стандартный ввод в зависимости от контекста.

Скажем, если кинуть ему в stdin ключ (не важно, открытый или закрытый), он автоматически импортирует его на связу(и), не задавая никаких вопросов. Более того, он сделает это, независимо от того, в какой части ввода поймает хидеры ключа. Зато если вызвать gpg -e, то ключ, он, конечно же не импортирует, а зашифрует.

Программу я всеми силами старался сделать context-agnostic. Единственная опция, являющаяся спэшл-кейсом в обработке — это --output/-o. Такой подход я считаю правильным, т.к. пытаться детально эмулировать поведение GnuPG в зависимости от контекста — всё равно, что прыгнуть в бездонный колодец; плюс GnuPG в любой момент может изменить своё поведение, открывая какие-то дырки на уровне выше.

Короче, как и думалось изначально, попытки выковыривать неудобные данные из stdin совершенно бесперспективны. Хотя лично мне не особо нравится, что клиент может безнаказанно кидать серверу на связку какие-то левые ключи, всё-таки не вижу в этом большого риска,¹ поэтому, если только кто-нибудь не сможет предложить элегантное решение, выведу модификацию связки из модели угрозы. В конечном счёте, на административном уровне решение существует: запускать сервер от пользователя, не имеющего доступ на запись файлов связок.

К слову, из-за того же моего нежелания разбирать контекст возникают некоторые другие неочивидные отличия в поведении программы.² В частности, если вызвать процесс gpg без параметров или с параметрами -s, -e и т.п., не передав ему ничего в stdin, он почему-то считает, что надо ожидать ввод из TTY и наглухо залипает. Подозреваю, что это можно как-то победить (хотя пока не знаю как), но до тех пор при пустом stdin передаю туда пустую строку — аналог cat /dev/null | gpg [...], из-за чего он может выплюнуть какой-то шифртекст или системную ошибку.

---

¹ Я думал над этим, но не могу перевести такую "особенность" в вектор атаки, разве что в крайнем случае DoS, если клиент засрёт серверу связку/диск ключами.
² Кстати, не нужно думать, будто в остальном поведение будет стандартным. Там куча отличий, специфических сообщений об ошибках и т.д.

Fxd


Проверяете вывод на наличие там блоков PRIVATE KEY?


Вы издеваетесь что ли? Вот вам три атаки. Могу раскрыть любую одну из них. Не продолжайте работу, пока не найдёте другие две.

1. Как почтовые и джаббер-программы определяют, какой приватный ключ использовать? Правильно, по KeyID'у (нередко ещё и укороченному). Атакующий добавляет на связку свой ключ с такими же параметрами и таким же укороченным uid'ом — всё, теперь ваши сообщения будут подписываться ключом атакующего. Правда, вы не сможете расшифровать вам приходящие сообщения (они будут зашифрованы настоящим ключом). Впрочем, это решаемый вопрос, если аналогичную атаку провести и на стороне вашего абонента. Могут быть нюансы, когда это всё же не сработает — допустим, на приватный ключ стоит пароль, который атакующий не знает.

2. То же, что и в предыдущем пункте, но не для вашего ключа, а для ключа ваших абонентов. В настроках почты и джаббера сидят всё те же KeyID'ы. Достаточно подобрать ключ с таким же KeyID'ом и сунуть его вам на связку, как вы начнёте шифровать сообщения этим подставным ключом, а не настоящим.³ Если делаем классический MITM, получается всё вообще шикарно. А ещё круче — это когда такая атака делается на обоих сторонах связи, тогда расшифровать можно весь поток сообщений в обе стороны.

3. Я не привык подписывать своим ключом другие. Если главный ключ связи хранится отдельно, а подпись надо сделать lsign, подписывание превращается в настоящий геморой — видимо, надо будет каждый раз стирать и копировать pubring. Когда я проверяю подпись, допустим, на TBB, я не помню наизусть отпечток Erinn, и на моей связке десятки ключей. Если однажды на ней появится подставной ключ Erinn с другим отпечатком, и подпись сверится по нему, подстава может пройти незамеченной.

Да, это хорошее замечение. Правда, не знаю, как это будет выглядеть технически. Дело в том, что в ~/.gnupg хранится в т.ч. регулярно обновляемый random_seed. Наверно, на ~/.gnupg надо выставить права rx, а на pubring.gpg и secring.gpg — r.⁴


А разе в командной строке он не так же себя ведёт? Наберите gpg и нажмите Eneter — он будет ждать ввода с TTY. Пока не нажмёте Ctrl+C (прерывание) или Ctrl+D (корректное завершение потока), он так и будет висеть:
P.S. Основная мысль: понять, какие опции нужны GnuPG для автоматической работы с почтой и джаббером, и разрешить только их. Т.е., белый лист вместо чёрного. Ну, и как ещё одна организационная мера — иметь много связок, каждая для своей цели, не класть все яйца в одну корзину. Например, там, где происходит ручная работа с командной строкой и под доверенным пользователем, этими навороченными интерфейсами можно вообще не пользоваться.

---

³ Могут быть нюансы с выбором приоритетов, но я про это не в курсе. Если бы это делалось в командной строке, GnuPG бы предложил выбрать один из двух ключей, т.к. KeyID не фиксирует конкретный, или нет? Не знаю, как с этим будет работать автоматика, когда это вызывается джаббером или почтовой программой.
⁴ Если на ~/.gnupg будет rwx, атакующий не сможет поменять существующие pubring.gpg и secring.gpg, но сможет просто их стереть и вместо них создать свои новые с такими же именами.

Там впереди частица "не", которую Вы, видимо, не заметили. У Вас получается, что если --import не заблэклищен (т.е. разрешён), то связка будет только для чтения.


Нет, это излишне.


Это ещё вопрос, кто тут издевается. :) Всё, перечисленное Вами — косяки на стороне пользователя и клиентских приложений. Ну, ещё можно кошку высушить в микроволновке, а потом подать в суд на производителя за то, что она кошка сломалась. GnuPG позволяет указывать ключи по полным отпечаткам, а если используете короткий keyID, да ещё без подписей, то просто дразните судьбу.


Эти файлы лежат в homedir, а связки не обязаны находиться там же. Всё это настраиваемо как через gpg.conf, так и непосредственно в конфиге сервера: можно указать, с какими опциями ему вызывать gpg, независимо даже от того, что содержится в gpg.conf.


Разница в том, что при вызове из консоли есть тот самый TTY, из которого можно ждать ввод, а при запуске процесса — нет. Но, как уже сказал, причина может быть в моих кривых руках.

Нет, дело не в этом, просто смысл не уловил сразу. Замечение принято.


Ну найдите нам другие приложения. Как вашему tkabber'у ключ задать? Можно по полному отпечатку? Мой клиент требует 16-ричный KeyID, насчёт полного отпечатка я не в курсе.

И, в конце концов, весь смысл этого проекта — костыль для латания дыр на стороне пользователя и его приложений, да. Если дыр нет, можно считать, что ключ никто не похитит.

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


В большинстве клиентских команд указывается 8-значный KeyID. Считается, что отпечаток однажды проверили, а двух ключей с одинаковыми KeyID'ами на связке нет.

Цель проекта — не дать пользователю вытащить закрытый ключ; это такая смарт-карта "для бедных", если хотите. Подпорки и костыли для UI и программных интерфейсов в клиентском ПО — это настолько out of the scope, насколько вообще возможно.


Разумеется, читать текущую переписку никто ему не запретит, это ведь именно дырявое клиентское ПО или атакующий передаёт gpg данные для шифрования.

Что касается импорта, я выше писал, что с удовольствием бы его запретил, существуй для этого какое-то лаконичное решение. Обучение программы семантике опций gpg таковым явно не является. Более того, оно и недостаточно, учитывая, что ввод может быть чисто бинарным (т.е. в нём может и не быть никаких PRIVATE/PUBLIC KEY BLOCK). Поэтому административное решение с блокированием записи связок представляется мне вполне достаточным и элегантным. Найдёте лучше — милости прошу.

Пожалуй, соглашусь.

Хотелось бы понять по поводу вайтлистинга. Его поддержка будет? Чтобы руками можно было задать, какие конкретно команды gpg могут быть выполнены [возможно, вплоть до конкретных KeyID'ов] (а все остальные должны блокироваться).

Кстати, всё-таки больше, чем смарт-карта за счёт возможности работы в распределённом режиме — сервер может крутиться на любой удалённой системе.


Заложена изначально. Фильтрации keyID нет в виду отсутствия разбора семантики. Хотя добавить фильтрацию параметров, в принципе, возможно, хорошая идея.

Я не вижу, чем KeyID'ы (значения опций) принципиально отличаются от собственно опций. Если есть фильтрация по опциям, то там же можно зафиксировать и параметры этих опций.

GPGIndustries:

What Could you Expect from GPGServer? We plan to release on 15th of June! Give us all you would expect from this server! We will do our best to implement it!

15-ое июня 2011-го уже прошло.

По сути, так и есть (технические детали несколько сложнее). Уже сделал.


Хех. Я обозвал поделие GPGRemote.

Тогда уж лучше назвать «GPG Remote» (раздельно), а сам исполнимый файл — как-то типа gpg-remote (по аналогии с gpg-agent, gpg-zip и т.д.).

Принято.

Значит, в очередной раз подтвердим "как корабль назовёте..." :)

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

Спасибо. На github'е будет или тут?