Регистрация18.02 // GPG Remote - использование GnuPG в относительно недоверенной среде
Использование GnuPG в сетевой среде всегда несёт риск того, что противник, способный скомпрометировать какое-либо из клиентских приложений (email-клиент, IM-клиент и т.п.), сможет с лёгкостью извлечь закрытые ключи, выполнив gpg --export-secret-keys. Смарткарты являются общепринятым решением данной проблемы, но сами они, в свою очередь, являются специализированными устройствами, которые 1) не всегда могут быть доступны пользователю либо 2) могут быть недоверяемы по тем или иным причинам.
GPG Remote — это клиент-серверное приложение, переносящее операции с закрытыми ключами GnuPG на удалённый сервер, исполняемый в безопасной доверенной системе. Сервер отфильтровывает клиентский ввод в соответствии с заданными правилами и запускает GnuPG, выступая посредником между программой и клиентом.
GPG Remote позволяет разделить процесс исполнения GnuPG между клиентом-фронтэндом и сервером-бекэндом. Клиентская часть приложения эмулирует консольный интерфейс GnuPG: принимает аргументы командной строки и данные, передаваемые пользователем через стандартный ввод (STDIN). Затем производится парсинг консольных аргументов и определение файлов, которые пользователь хотел передать GnuPG для обработки. Из этих данных формируется пакет запроса, который передаётся серверу.
Сервер работает в доверенной среде, его задача — выполнить gpg безопасным образом. Этой цели служит белый список консольных опций gpg, согласно которому сервер отфильтровывает полученные от клиента аргументы командной строки (прежде всего, команды типа --export-secret-keys). Клиентские файлы сохраняются во временную директорию, а их пути в аргументах командной строки соответствующим образом заменяются. Наконец, сервер вызывает gpg, а вывод программы (состоящий из потоков STDERR и STDOUT, кода завершения программы, а также сгенерированных файлов) посылается обратно клиенту.
Источник: https://www.pgpru.com/razrabotki/gpgremote
Клиент копирует файл, требующий расшифровки или подписи в /tmp, чтобы сделать его доступным серверу, или как?
комментариев: 11558 документов: 1036 редакций: 4118
Если данные передаются в зашифрованном виде с помощью ssl, то что мешает скомпроментированному клиенту все эти данные перехватывать? Возможен и гораздо более вероятен перехват данных и на пути между клиентом и сервером.
Единственно на что может годится, как я понял, это подписывать открытые данные.
комментариев: 11558 документов: 1036 редакций: 4118
В документации чёрным по белому написано:
Хочу напомнить, что использовать GPG Remote на отдельных системах не обязательно, можно и на одной под разными пользователями.
Кажется, Вы не понимаете, какую задачу решает GPG Remote. Его цель только в том, чтобы не дать клиенту или какому-либо из его локальных приложений скомпрометировать долговременный секрет — закрытый ключ. При этом ничто не мешает (и в принципе не может помешать) этому приложению скомпрометировать передаваемые данные — это вообще за рамками модели угрозы.
В качестве примера. Допустим, пользователь опасается, что в его jabber- или email-клиенте содержится уязвимость, благодаря которой злоумышленник может скопировать закрытый ключ, которым подписываются/расшифровываются сообщения. Тогда он может установить и настроить GPG Remote. В этом случае пользовательское приложение уже не будет взаимодействовать с gpg напрямую и не сможет выполнить --export-secret-keys (одновременно с этим утащив пассфразу с помощью кейлоггера), что исключает риск расшифрования прежней переписки. В то же время, ничто не мешает скомпрометированному приложению сливать на сторону новую переписку. Своего рода PFS. Так или иначе, GPG Remote защищает именно ключ, а не данные.
Пассфразу-то кто ему запретит похитить? Это же у вас выносится за скобки в модели угрозы. Пассфразу передаёт серверу клиент, поэтому уязвимый клиент может подменить pinentry собственной программой.
комментариев: 11558 документов: 1036 редакций: 4118
Никто, я же выше ясно написал:
Наличие GPG Remote не способно защитить парольную фразу на скомпрометированном клиенте. Но суть в том, что без самого ключа противнику от неё не будет никакой пользы.
Кстати, PFS в чистом виде здесь, конечно, нет: при компрометации пассфразы противник вполне может расшифровать данные, к которым имеет доступ, выполнив эту операцию через GPG Remote (пока пользователь, например, не уберёт ключ со связки).
Правильное замечание. Ключ хоть и не украден, при консервативном подходе все данные всё равно надо считать скомпрометированными и менять подключ.
В чём тогда смысл затеи с gpg-remote? ☺ Только в техническом усложнении расшифровки этих данных.комментариев: 11558 документов: 1036 редакций: 4118
В чём тогда смысл затеи с gpg-remote? ☺ Только в техническом усложнении расшифровки этих данных.Степень контроля всё равно выше. Плюс, учитывая, что ведётся подробный лог операций, есть возможность как обнаружить неладное, так и автоматизировать какие-то контрмеры.
комментариев: 9796 документов: 488 редакций: 5664
Самое безопасное — использовать GPG-флоппинет, он же GPG-Airgap.
И разрабатывать ничего не надо. Поэтому местные параноики и не проявили особого интереса к проекту.
[/петросянство]
Как сказал мне один человек, самая лучшая защита секрета — это его отсутствие. Нет секретов — нет проблем, поэтому настоящие параноики вообще ничего не шифруют и компьютеров не держат, нечего им шифровать.
[/петросянство]
комментариев: 11558 документов: 1036 редакций: 4118
Настоящим параноикам нечего скрывать.
[/петросянство]
комментариев: 11558 документов: 1036 редакций: 4118
В принципе, добавить подобие PFS (операционного, не криптографического) можно с помощью OTP. Пользователь генерирует на сервере серию коротких паролей, сервер их сохраняет локально, а пользователь записывает на бумажке/распечатывает/делает копию на смартфон (что удобнее/уместнее/безопаснее). Затем при использовании закрытого ключа пользователь дописывает такой пароль из списка к своей парольной фразе в диалоге pinentry и вычёркивает/удаляет его из списка. Если пароль верный, сервер обрабатывает запрос, как положено. Таким образом, компрометация пассфразы закрытого ключа сама по себе не позволит противнику воспользоваться ключом через GPG Remote.
Вообще, у меня есть стойкое ощущение, что там, где позарез нужна PFS, вместо доморощенных PGP-велосипедов нужно полагаться на Tor и OTR, потому что своими костылями сильно это не улучшить, а переусложнение получается огромным.
комментариев: 11558 документов: 1036 редакций: 4118
Ну да, это скорее просто механизм контроля доступа.