Издање ОпенССХ 8.2 са подршком за ФИДО/У2Ф двофакторске токене за аутентификацију

После четири месеца развоја представљени издање ОпенССХ КСНУМКС, имплементација отвореног клијента и сервера за рад преко ССХ 2.0 и СФТП протокола.

Кључно побољшање у издању ОпенССХ 8.2 била је могућност коришћења двофакторске аутентификације помоћу уређаја који подржавају протокол УКСНУМКСФ, развијен од стране алијансе ФИДО. У2Ф омогућава креирање јефтиних хардверских токена за верификацију физичког присуства корисника, у интеракцији са њима преко УСБ-а, Блуетоотх-а или НФЦ-а. Такви уређаји се промовишу као средство двофакторске аутентификације на веб локацијама, већ их подржавају главни претраживачи и производе их различити произвођачи, укључујући Иубицо, Феитиан, Тхетис и Кенсингтон.

За интеракцију са уређајима који потврђују присуство корисника, ОпенССХ-у су додати нови типови кључева „ецдса-ск“ и „ед25519-ск“, који користе алгоритме дигиталног потписа ЕЦДСА и Ед25519 у комбинацији са СХА-256 хешом. Процедуре за интеракцију са токенима су смештене у међубиблиотеку, која се учитава на сличан начин као библиотека за подршку ПКЦС#11 и представља омотач на врху библиотеке либфидо2, који обезбеђује алате за комуникацију са токенима преко УСБ-а (подржани су протоколи ФИДО У2Ф/ЦТАП 1 и ФИДО 2.0/ЦТАП 2). Средња библиотека либск-либфидо2 коју су припремили ОпенССХ програмери укључени у језгро либфидо2, као и ХИД драјвер за ОпенБСД.

Да бисте потврдили аутентичност и генерисали кључ, морате да наведете параметар „СецуритиКеиПровидер“ у подешавањима или поставите променљиву окружења ССХ_СК_ПРОВИДЕР, назначујући путању до екстерне библиотеке либск-либфидо2.со (извоз ССХ_СК_ПРОВИДЕР=/патх/то/либск-либфидо2. тако). Могуће је направити опенссх са уграђеном подршком за библиотеку слојева (--витх-сецурити-кеи-буилтин), у овом случају морате подесити параметар „СецуритиКеиПровидер=интернал“.
Затим морате да покренете „ссх-кеиген -т ецдса-ск“ или, ако су кључеви већ креирани и конфигурисани, да се повежете са сервером помоћу „ссх“. Када покренете ссх-кеиген, генерисани пар кључева биће сачуван у „~/.ссх/ид_ецдса_ск“ и може се користити слично другим кључевима.

Јавни кључ (ид_ецдса_ск.пуб) треба копирати на сервер у датотеци аутхоризед_кеис. На страни сервера се верификује само дигитални потпис, а интеракција са токенима се обавља на страни клијента (не морате да инсталирате либск-либфидо2 на серверу, али сервер мора да подржава тип кључа „ецдса-ск“) . Генерисани приватни кључ (ид_ецдса_ск) је у суштини рукохват кључа, који формира прави кључ само у комбинацији са тајном секвенцом ускладиштеном на страни токена У2Ф. Ако кључ ид_ецдса_ск падне у руке нападача, да би прошао аутентификацију, он ће такође морати да добије приступ хардверском токену, без којег је приватни кључ сачуван у датотеци ид_ецдса_ск бескористан.

Поред тога, подразумевано, када се обављају било какве операције са кључевима (како током генерисања тако и током аутентификације), потребна је локална потврда физичког присуства корисника, на пример, предлаже се додиривање сензора на токену, што отежава врши даљинске нападе на системе са повезаним токеном. Као још једна линија одбране, лозинка се такође може навести током фазе покретања ссх-кеигена за приступ датотеци кључа.

Нова верзија ОпенССХ-а је такође најавила предстојећу застарелост алгоритама који користе СХА-1 хешове због унапређење ефикасност напада колизије са датим префиксом (трошак одабира колизије се процењује на приближно 45 хиљада долара). У једном од наредних издања планирају да подразумевано онемогуће могућност коришћења алгоритма за дигитални потпис јавног кључа „ссх-рса“, који се помиње у оригиналном РФЦ-у за ССХ протокол и остаје широко распрострањен у пракси (да би се тестирала употреба ссх-рса у вашим системима, можете покушати да се повежете преко ссх са опцијом „-оХостКеиАлгоритхмс=-ссх-рса“).

Да би се олакшао прелазак на нове алгоритме у ОпенССХ-у, у будућем издању ће поставка УпдатеХостКеис бити подразумевано омогућена, што ће аутоматски мигрирати клијенте на поузданије алгоритме. Препоручени алгоритми за миграцију укључују рса-сха2-256/512 заснован на РФЦ8332 РСА СХА-2 (подржан од ОпенССХ 7.2 и користи се подразумевано), ссх-ед25519 (подржан од ОпенССХ 6.5) и заснован на ецдса-сха2-нистп256/384 на РФЦ521 ЕЦДСА (подржано од ОпенССХ 5656).

У ОпенССХ 8.2, могућност повезивања помоћу „ссх-рса“ је и даље доступна, али је овај алгоритам уклоњен са листе ЦАСигнатуреАлгоритхмс, која дефинише алгоритме дозвољене за дигитално потписивање нових сертификата. Слично томе, алгоритам диффие-хеллман-гроуп14-сха1 је уклоњен из подржаних подразумеваних алгоритама за размену кључева. Примећује се да је употреба СХА-1 у сертификатима повезана са додатним ризиком, пошто нападач има неограничено време да тражи колизију за постојећи сертификат, док је време напада на кључеве хоста ограничено тимеоутом везе (ЛогинГрацеТиме ).

Покретање ссх-кеиген сада подразумевано подразумева алгоритам рса-сха2-512, који је подржан од ОпенССХ 7.2, што може да створи проблеме са компатибилношћу када покушава да обради сертификате потписане у ОпенССХ 8.2 на системима који користе старија ОпенССХ издања (да би се решио проблем када када генеришући потпис, можете експлицитно навести „ссх-кеиген -т ссх-рса“ или користити алгоритме ецдса-сха2-нистп256/384/521, подржане од ОпенССХ 5.7).

Остале промене:

• Директива Инцлуде је додата у ссхд_цонфиг, која вам омогућава да укључите садржај других датотека на тренутној позицији конфигурационе датотеке (глоб маске се могу користити када се специфицира име датотеке);
• Опција „но-тоуцх-рекуиред” је додата у ссх-кеиген, што онемогућава потребу да се физички потврди приступ токену приликом генерисања кључа;
• Директива ПубкеиАутхОптионс је додата у ссхд_цонфиг, која комбинује различите опције везане за аутентификацију јавног кључа. Тренутно је подржана само ознака „захтева се без додира“ да би се прескочиле провере физичког присуства за аутентификацију токеном. По аналогији, опција „но-тоуцх-рекуиред” је додата датотеци аутхоризед_кеис;
• Додата опција „-О врите-аттестатион=/патх“ у ссх-кеиген да би се омогућило писање додатних ФИДО сертификата приликом генерисања кључева. ОпенССХ још увек не користи ове сертификате, али се касније могу користити за проверу да ли је кључ смештен у поуздану продавницу хардвера;
• У подешавањима ссх и ссхд, сада је могуће подесити режим приоритета саобраћаја преко ИПКоС директиве ЛЕ ДСЦП (Понашање мањег напора по скоку);
• У ссх-у, када поставите вредност „АддКеисТоАгент=иес“, ако кључ не садржи поље за коментар, биће додат ссх-агент-у који означава путању до кључа као коментар. ИН
  ссх-кеиген и ссх-агент такође сада користе ПКЦС#11 ознаке и Кс.509 име субјекта уместо путање библиотеке као коментаре у кључу;

• Додата могућност извоза ПЕМ за ДСА и ЕЦДСА кључеве у ссх-кеиген;
• Додат је нови извршни програм, ссх-ск-хелпер, који се користи за изоловање библиотеке приступа ФИДО/У2Ф токенима;
• Додата „--витх-злиб“ опција изградње за ссх и ссхд за компилацију са подршком за злиб библиотеку;
• У складу са захтевом РФЦ4253, упозорење о блокирању приступа због прекорачења МакСтартупс ограничења се налази на банеру који се приказује током повезивања. Да би се поједноставила дијагностика, заглавље ссхд процеса, видљиво када се користи пс услужни програм, сада приказује број тренутно потврђених веза и статус ограничења МакСтартупс;
• У ссх и ссх-агент-у, приликом позивања програма да прикаже позивницу на екрану, специфицирану преко $ССХ_АСКПАСС, сада се додатно преноси ознака са врстом позивнице: „цонфирм” - дијалог за потврду (да/не), „ноне ” - информативна порука, „празно” — захтев за лозинку;
• Додата је нова операција дигиталних потписа „пронађи принципале“ у ссх-кеиген за претраживање датотеке дозвољених потписника за корисника повезаног са наведеним дигиталним потписом;
• Побољшана подршка за изолацију ссхд процеса на Линук-у помоћу механизма сеццомп: онемогућавање ИПЦ системских позива, омогућавање цлоцк_геттиме64(), цлоцк_нанослееп_тиме64 и цлоцк_нанослееп().

Извор: опеннет.ру