Как можно написать систему закрытого / открытого ключей для аутентификации сервера?

Я предполагаю, что это могло быть где-то размещено, я искал, но ничего не нашел.

У меня есть этот сервер, на котором я запускаю игровой сервер, и где я хочу иметь какой-нибудь TCP-сервер (возможно, написанный на Ruby), который будет предоставлять псевдосеанс с несколькими доступными командами (например, перезапустить игровой сервер, отправить журналы и т. Д. .)

Я хочу аутентификацию, подобную SSH, где у людей есть открытые и частные ключи DSA (которые я знаю, как сгенерировать), а открытый ключ распознается сервером как правильная аутентификация.

Я не ищу реализацию кода, а в основном то, как это должно быть построено.

Я думал примерно так:

  • [Client] Подключиться к серверу
  • [Server] Отправить открытый ключ
  • [Client] Отправить открытый ключ, закодированный с открытым ключом сервера
  • [Server] Сравните ключ с базой авторизованных клиентов
  • [Server] Сгенерировать сеансовый ключ, отправить его в зашифрованном виде с помощью клиентского паба
  • [Client] Расшифровывает сеансовый ключ и начинает отправлять сообщения, всегда сопровождаемые сеансовым ключом.

Но я чувствую, что здесь чего-то не хватает. Особенно, когда я смотрю на системы DSA и PK, я продолжаю видеть подписывание сообщений, и я не уверен, что понимаю, чем это отличается от использования ключей публикации для шифрования и ключа сеанса?

Если мой вопрос непонятен, я, конечно, буду рад отредактировать свой пост :-).


person Thibault Martin-Lagardette    schedule 13.08.2010    source источник
comment
не забывайте метку времени или одноразовый номер, чтобы не подвергаться атакам повторного воспроизведения   -  person cobbal    schedule 14.08.2010


Ответы (3)


Почему бы не использовать SSH вместо SSH? Или использовать SSL, который почти повсеместно поддерживает библиотеки для любой платформы?

Во-первых, так проще. Код написан, протестирован, проанализирован и поддерживается.

Во-вторых, так безопаснее. Если вы не понимаете, зачем нужно подписывать сообщения, что еще вы могли упустить? Честно говоря, даже TLS (SSL), который подвергся тщательной проверке, имел серьезный недостаток в ошибке повторного согласования, о которой недавно было объявлено. Даже если вы знаете, что делаете, разработать безопасный протокол сложно.

Между прочим, SSH и SSL вычисляют код аутентификации сообщения для каждой записи протокола, так что злоумышленник не может вмешаться в содержимое сообщения.

person erickson    schedule 13.08.2010
comment
О SSH не может быть и речи, я не хочу, чтобы у них был реальный доступ к машине через оболочку. Однако я полностью понимаю суть SSL. Почему-то я подумал, что это не совсем то. Фактически, я не знал, что сертификаты X.509 могут играть роль системы PK. Затем я займусь этим, спасибо, что направили меня в лучшем направлении! - person Thibault Martin-Lagardette; 14.08.2010
comment
@ ThibaultMartin-Lagardette SSH не обязательно должен подразумевать «реальный доступ оболочки к машине». Вы можете ограничиться только общением. - person user207421; 20.03.2017

Если вам нужна реализация, подобная SSL, почему бы просто не использовать SSL?

person Zimm3r    schedule 13.08.2010

Если вы все же решите пойти по пути реализации собственного уровня безопасности (что иногда является правильным ответом), следует помнить о многих тонкостях. Начните с прочтения того, что я считаю окончательной могилой по этой теме:

Прикладная криптография Брюса Шнайера

person Kaelin Colclasure    schedule 13.08.2010