Как може да се напише система с частен/публичен ключ за удостоверяване на сървър?

Предполагам, че това може да е публикувано някъде, търсих, но не намерих нищо.

Имам този сървър, на който стартирам сървър за игри и където искам да има някакъв TCP сървър (евентуално написан на Ruby), който ще осигури псевдосесия с няколко налични команди (като рестартиране на сървъра за игри, изпращане на регистрационни файлове и т.н. .)

Това, което искам, е подобно на SSH удостоверяване, при което хората имат публични и частни DSA ключове (които знам как да генерирам), а публичният ключ се разпознава от сървъра като правилно удостоверяване.

Не търся внедряване на код, а главно как това трябва да бъде архитектурирано.

Това, което си мислех, беше нещо като:

  • [Client] Свържете се със сървъра
  • [Server] Изпратете публичен ключ
  • [Client] Изпратете публичен ключ, кодиран с публичния ключ на сървъра
  • [Server] Сравнете ключа с база данни от оторизирани клиенти
  • [Server] Генерирайте ключ за сесия, изпратете го шифрован с pub на клиента
  • [Client] Декодира сесийния ключ и започва да изпраща съобщения, винаги придружени от сесийния ключ

Но имам чувството, че нещо липсва. Особено, когато разглеждам DSA и PK системите, продължавам да виждам подписване на съобщения и не съм сигурен, че разбирам колко различно е от използването на pub ключове за криптиране и сесийния ключ?

Ако въпросът ми не е ясен, ще се радвам да редактирам поста си, разбира се :-).


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


Отговори (3)


Вместо подобно на SSH, защо не използвате SSH? Или да използвате SSL, който има почти повсеместна поддръжка на библиотека за всяка платформа?

Първо, по-лесно е. Кодът е написан, тестван, прегледан и поддържан.

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

Между другото, SSH и SSL изчисляват код за удостоверяване на съобщението за всеки запис на протокол, така че човекът по средата да не може да подправя съдържанието на съобщението.

person erickson    schedule 13.08.2010
comment
SSH не може да става, не искам те да имат истински shell достъп до машината. Въпреки това напълно разбирам идеята за 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