#ssh #cryptography #blockchain #public-key-encryption #public-key
#ssh #криптография #блокчейн #шифрование с открытым ключом #открытый ключ
Вопрос:
Я разрабатываю криптовалюту на основе блокчейна, и некоторые блоки в блокчейне могут обновлять свои данные владельцем блока. Я попытался реализовать ssh-стиль аутентификации с открытым ключом: клиент генерирует пару ключей и отправляет открытый ключ в блок, где он позволяет открытым ключам, перечисленным в разделе «администраторы», изменять метаданные блока. Проблема в том, что кто-то может отправлять случайные известные открытые ключи, чтобы узнать, разрешено ли им редактировать метаданные, как ssh мешает людям просто отправлять какую-то строку с известным открытым ключом для доступа к содержимому ssh? (Я спрашиваю об этом, потому что хочу реализовать что-то похожее на мой контекст)
Комментарии:
1. «Проблема в том, что кто-то может отправлять случайные известные открытые ключи, чтобы узнать, разрешено ли им редактировать метаданные» Почему вы так думаете? Одним из основных свойств блокчейна является то, что он остается неизменным после того, как он подписан блоками выше по цепочке. Это означало бы, что открытые ключи в разделе «администраторы» не могут быть изменены. Итак, если вы хотите добавить сообщение в более поздний блок, который ссылается на «ваш» блок, вы должны подписать сообщение закрытым ключом, который соответствует открытому ключу, хранящемуся в «вашем» блоке. У вас может быть тип сообщения для добавления открытых ключей, который также подписан
2. Архитектура, которую я создал, оставляет желать лучшего. Когда блок, принадлежащий частной сущности, обновляется, он запрашивает открытый ключ (хранящийся в одном из полей блока) и вместе с ним либо добавляет, удаляет, либо изменяет конкретный ключ и / или поле, хранящиеся в блоке. Итак, если вы знаете открытый ключ (который может появиться в распределительной книге), которому разрешено изменять данные, вы можете изменить блок, который не принадлежит вам, и обновить его дальше по цепочке. Я уверен, что, возможно, думал о более безопасном способе сделать это, и я поделюсь своими выводами, когда это сработает. Спасибо за ваш ответ.
Ответ №1:
Не уверен, действительно ли это вопрос программирования, но:
SSH использует открытые ключи для аутентификации «хостов» (серверов) всегда и «пользователей» (клиентов) необязательно (но часто). Обычно используемая и де-факто стандартная реализация OpenSSH в последнем случае использует файл для каждого пользователя на сервере, обычно расположенный в домашнем каталоге пользователя as $HOME/.ssh/authorized_keys , в котором перечислены общедоступные ключи, действительные для этого пользователя. Если клиентский процесс указывает имя пользователя и общедоступный ключ, перечисленные в файле authorized_keys этого пользователя, и использует privatekey для подписи определенных данных, включая секрет соединения и одноразовые номера, это считается подтверждением личности пользователя. (Подробности см. В RFC 4252, но для контекста начните с 4253.) Другие реализации должны иметь эквивалентные данные, хотя и не обязательно этот точный файл. Хост / сервер обычно позволяет пользователю / клиенту предпринять несколько попыток, если у него есть несколько ключей и / или других методов, но это настраивается.
SSH сам по себе в основном не контролирует доступ; он просто устанавливает идентификатор пользователя / клиента как имя пользователя, настроенное на «хосте». Использование этого идентификатора для управления доступом — то, что специалисты по безопасности называют авторизацией, в отличие от идентификации и аутентификации, — зависит от хоста. Многие хосты SSH являются Unix, и для Unix применяются те же правила для доступа к Unix по SSH, что и для других типов соединений: это начинается с классических «битов chmod» в каждом файле, разрешающих чтение, запись, выполнение пользователю, группе, другим, и может включать другие вещи, такие как ACL, SELinuxатрибуты, правила sudo, групповое соответствие для процессов сигнализации, специальная конфигурация некоторых вещей, таких как NFS, и так далее, и так далее. Если SSH-хост / сервер НЕ является Unix, какие правила или политики безопасности он применяет после подключения и аутентификации, зависят от него и могут быть совершенно разными.
OpenSSH (на хосте Unix) также реализует несколько параметров в authorized_keys файле, которые налагают дополнительные ограничения на то, что может делать клиент (через это соединение); см. man sshd в вашей системе или здесь в разделе ФОРМАТ ФАЙЛА AUTHORIZED_KEYS . Кроме того, как отмечено там, OpenSSH поддерживает уровень косвенности: вместо прямого перечисления каждого ключа в файле authorized_keys каждого соответствующего пользователя вы можете использовать (назначенный) ключ CA для подписи других ключей, а затем настроить authorized_keys для принятия любого ключа, подписанного указанным ключом CA. Эти сертификаты сами по себе могут включать некоторые ограничения; см. man ssh-keygen в разделе СЕРТИФИКАТЫ. Это может быть более удобно в большой среде со многими пользователями, хостами или обоими.
Комментарии:
1. Очень проницательный и полезный. Спасибо за ваш ответ. Я усвою эти знания с помощью приложения и обновлю эту тему, когда добьюсь успеха в безопасности.