OpenPGP crypto key
Привет.
Я думаю над проектом устройства, реализующего необходимые для конфиденциальной переписки криптографические функции. Мотив в том, чтобы предотвратить доступ к хранилищу ключей с потенциально скомпрометированного компьютера. Вопрос – как организовать интерфейс взаимодействия устройства с хостом. В конечном счёте, хотелось бы получить решение, полностью совместимое с протоколом openpgp: формат ключей, сообщений, подписей и прочее. Чтобы мне не изобретать велосипеды, может быть, вы подскажете какие стандартные решения в этой области применимы? Читал, что есть стандарт PKCS #11, но пока не ознакомился с документацией. Он будет пригоден для моей задачи?
Спасибо!
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
читает мысли пользователяпарсит стандартный ввод в зависимости от контекста.Скажем, если кинуть ему в stdin ключ (не важно, открытый или закрытый), он автоматически импортирует его на связу(и), не задавая никаких вопросов. Более того, он сделает это, независимо от того, в какой части ввода поймает хидеры ключа. Зато если вызвать gpg -e, то ключ, он, конечно же не импортирует, а зашифрует.
Программу я всеми силами старался сделать context-agnostic. Единственная опция, являющаяся спэшл-кейсом в обработке — это --output/-o. Такой подход я считаю правильным, т.к. пытаться детально эмулировать поведение GnuPG в зависимости от контекста — всё равно, что прыгнуть в бездонный колодец; плюс GnuPG в любой момент может изменить своё поведение, открывая какие-то дырки на уровне выше.
Короче, как и думалось изначально, попытки выковыривать неудобные данные из stdin совершенно бесперспективны. Хотя лично мне не особо нравится, что клиент может
безнаказаннокидать серверу на связку какие-то левые ключи, всё-таки не вижу в этом большого риска,1 поэтому, если только кто-нибудь не сможет предложить элегантное решение, выведу модификацию связки из модели угрозы. В конечном счёте, на административном уровне решение существует: запускать сервер от пользователя, не имеющего доступ на запись файлов связок.К слову, из-за того же моего нежелания разбирать контекст возникают некоторые другие неочивидные отличия в поведении программы.2 В частности, если вызвать процесс gpg без параметров или с параметрами -s, -e и т.п., не передав ему ничего в stdin, он почему-то считает, что надо ожидать ввод из TTY и наглухо залипает. Подозреваю, что это можно как-то победить (хотя пока не знаю как), но до тех пор при пустом stdin передаю туда пустую строку — аналог cat /dev/null | gpg [...], из-за чего он может выплюнуть какой-то шифртекст или системную ошибку.
1 Я думал над этим, но не могу перевести такую "особенность" в вектор атаки, разве что в крайнем случае DoS, если клиент засрёт серверу связку/диск ключами.
2 Кстати, не нужно думать, будто в остальном поведение будет стандартным. Там куча отличий, специфических сообщений об ошибках и т.д.
вайтлиститьблэклистить опции типа --import, то связка будет фактически только для чтения.Fxd
Проверяете вывод на наличие там блоков PRIVATE KEY?
Вы издеваетесь что ли?
Вот вам три атаки. Могу раскрыть любую одну из них. Не продолжайте работу, пока не найдёте другие две.Да, это хорошее замечение. Правда, не знаю, как это будет выглядеть технически. Дело в том, что в ~/.gnupg хранится в т.ч. регулярно обновляемый random_seed. Наверно, на ~/.gnupg надо выставить права rx, а на pubring.gpg и secring.gpg — r.4
А разе в командной строке он не так же себя ведёт? Наберите gpg и нажмите Eneter — он будет ждать ввода с TTY. Пока не нажмёте Ctrl+C (прерывание) или Ctrl+D (корректное завершение потока), он так и будет висеть:
P.S. Основная мысль: понять, какие опции нужны GnuPG для автоматической работы с почтой и джаббером, и разрешить только их. Т.е., белый лист вместо чёрного. Ну, и как ещё одна организационная мера — иметь много связок, каждая для своей цели, не класть все яйца в одну корзину. Например, там, где происходит ручная работа с командной строкой и под доверенным пользователем, этими навороченными интерфейсами можно вообще не пользоваться.
3 Могут быть нюансы с выбором приоритетов, но я про это не в курсе. Если бы это делалось в командной строке, GnuPG бы предложил выбрать один из двух ключей, т.к. KeyID не фиксирует конкретный, или нет? Не знаю, как с этим будет работать автоматика, когда это вызывается джаббером или почтовой программой.
4 Если на ~/.gnupg будет rwx, атакующий не сможет поменять существующие pubring.gpg и secring.gpg, но сможет просто их стереть и вместо них создать свои новые с такими же именами.
комментариев: 11558 документов: 1036 редакций: 4118
вайтлиститьблэклистить опции типа --import, то связка будет фактически только для чтения.FxdBroken. :PТам впереди частица "не", которую Вы, видимо, не заметили. У Вас получается, что если --import не заблэклищен (т.е. разрешён), то связка будет только для чтения.
Нет, это излишне.
Это ещё вопрос, кто тут издевается. :) Всё, перечисленное Вами — косяки на стороне пользователя и клиентских приложений. Ну, ещё можно кошку высушить в микроволновке, а потом подать в суд на производителя за то, что
онакошка сломалась. GnuPG позволяет указывать ключи по полным отпечаткам, а если используете короткий keyID, да ещё без подписей, то просто дразните судьбу.Эти файлы лежат в homedir, а связки не обязаны находиться там же. Всё это настраиваемо как через gpg.conf, так и непосредственно в конфиге сервера: можно указать, с какими опциями ему вызывать gpg, независимо даже от того, что содержится в gpg.conf.
Разница в том, что при вызове из консоли есть тот самый TTY, из которого можно ждать ввод, а при запуске процесса — нет. Но, как уже сказал, причина может быть в моих кривых руках.
Нет, дело не в этом, просто смысл не уловил сразу. Замечение принято.
Ну найдите нам другие приложения. Как вашему tkabber'у ключ задать? Можно по полному отпечатку? Мой клиент требует 16-ричный KeyID, насчёт полного отпечатка я не в курсе.
И, в конце концов, весь смысл этого проекта — костыль для латания дыр на стороне пользователя и его приложений, да. Если дыр нет, можно считать, что ключ никто не похитит.
Правда, если глубоко копать, то можно вглянуть на проблему с другой стороны: если у атакующего есть права на выполнение произвольного кода и изменение конфигурационных файлов, то, тем более, у него есть права на чтение переписки из-под этого пользователя. Тут можно напереть разве что на то, что в конфиги и на связку будут внесены незаметные изменения, которые далеко не сразу будут обнаружены.
В большинстве клиентских команд указывается 8-значный KeyID. Считается, что отпечаток однажды проверили, а двух ключей с одинаковыми KeyID'ами на связке нет.
комментариев: 11558 документов: 1036 редакций: 4118
Цель проекта — не дать пользователю вытащить закрытый ключ; это такая смарт-карта "для бедных", если хотите. Подпорки и костыли для UI и программных интерфейсов в клиентском ПО — это настолько out of the scope, насколько вообще возможно.
Разумеется, читать текущую переписку никто ему не запретит, это ведь именно дырявое клиентское ПО или атакующий передаёт gpg данные для шифрования.
Что касается импорта, я выше писал, что с удовольствием бы его запретил, существуй для этого какое-то лаконичное решение. Обучение программы семантике опций gpg таковым явно не является. Более того, оно и недостаточно, учитывая, что ввод может быть чисто бинарным (т.е. в нём может и не быть никаких PRIVATE/PUBLIC KEY BLOCK). Поэтому административное решение с блокированием записи связок представляется мне вполне достаточным и элегантным. Найдёте лучше — милости прошу.
Пожалуй, соглашусь.
Хотелось бы понять по поводу вайтлистинга. Его поддержка будет? Чтобы руками можно было задать, какие конкретно команды gpg могут быть выполнены [возможно, вплоть до конкретных KeyID'ов] (а все остальные должны блокироваться).
комментариев: 11558 документов: 1036 редакций: 4118
Кстати, всё-таки больше, чем смарт-карта за счёт возможности работы в распределённом режиме — сервер может крутиться на любой удалённой системе.
Заложена изначально. Фильтрации keyID нет в виду отсутствия разбора семантики. Хотя добавить фильтрацию параметров, в принципе, возможно, хорошая идея.
Я не вижу, чем KeyID'ы (значения опций) принципиально отличаются от собственно опций. Если есть фильтрация по опциям, то там же можно зафиксировать и параметры этих опций.
GPGIndustries:
15-ое июня 2011-го уже прошло.
комментариев: 11558 документов: 1036 редакций: 4118
По сути, так и есть (технические детали несколько сложнее). Уже сделал.
Хех. Я обозвал поделие GPGRemote.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
Код готов, документация плюс-минус тоже. Хочу ещё немного потестить, дописать юниттестов. Выложу для публичного тестирования через пару дней.