Як вядома, у /dev/random, крыптаграфічна ўстойлівага генератара псеўдавыпадковых лікаў (CSPRNG), маецца адна непрыемная праблема – блакаванні. У дадзеным артыкуле распавядаецца, якім чынам можна яго вырашыць.
За апошнія некалькі месяцаў сродкі генерацыі выпадковых лікаў у ядры былі крыху перапрацаваны, але праблемы ў гэтай падсістэме вырашаліся на працягу больш шырокіх. . Самыя былі зроблены з мэтай прадухіліць працяглую блакіроўку сістэмнага выкліку getrandom () пры загрузцы сістэмы, але прычынай, якая ляжыць у аснове гэтага, было паводзіны блакавальнага выпадковага пула. Нядаўні патч выдаліў бы гэты пул, і, трэба было чакаць, што ён накіруецца да асноўнага ядра.
Эндзі Лутамірскі (Andy Lutomirski) апублікаваў трэцюю версію патча ў канцы снежня. Ён уносіць "два асноўных семантычных змены ў выпадковых API Linux". Патч дадае новы сцяг GRND_INSECURE да сістэмнага выкліку getrandom() (хоць Лутамірскі звяртаецца да яго як да getentropy(), які рэалізаваны ў glibc з дапамогай getrandom() з фіксаванымі сцягамі); гэты сцяг прымушае выклік заўсёды вяртаць колькасць запытаных даных, але без гарантыі, што гэтыя дадзеныя выпадковыя. Ядро проста прыкладзе ўсе намаганні, каб даць найлепшыя выпадковыя дадзеныя, якія ў яго ёсць на дадзены момант часу. «Верагодна, лепшае, што можна зрабіць, гэта назваць яго „INSECURE“ (небяспечным), каб перашкодзіць выкарыстанню гэтага API для рэчаў, якія маюць патрэбу ў бяспецы».
Патчы таксама выдаляюць блакуючы пул. У цяперашні час ядро падтрымлівае два пулы выпадковых дадзеных, адзін з якіх адпавядае /dev/random, а іншы - /dev/urandom, як апісана ў гэтай 2015 года. Блакуючы пул - гэта пул для /dev/random; чытанне для гэтай прылады будзе блакавацца (маецца на ўвазе яго імя) датуль, пакуль з сістэмы не будзе сабрана "дастатковая" энтрапія для задавальнення запыту. Далейшыя чытанні з гэтага файла таксама блакуюцца, калі ў пуле недастаткова энтрапіі.
Выдаленне пула блакіровак азначае, што чытанне з /dev/random паводзіць сябе як getrandom() са значэннем flags роўным нулю (і ператварае сцяг GRND_RANDOM у noop). Пасля ініцыялізацыі крыптаграфічнага генератара выпадковых лікаў (CRNG), чытанне з /dev/random і выклікі getrandom(…,0) не прывядзе да блакавання і верне патрэбную колькасць выпадковых дадзеных.
Лутамірскі кажа: «Я лічу, што блакуючы пул Linux зжыў сябе. CRNG Linux генеруе выходныя дадзеныя, якія дастаткова добрыя, каб выкарыстоўваць іх нават для генерацыі ключоў. Блакуючы пул не з'яўляецца мацнейшым у любым матэрыяльным стаўленні, і для яго падтрымання патрабуецца шмат інфраструктуры сумнеўнай каштоўнасці».
Змены былі зроблены з прыцэлам на тое, каб існуючыя праграмы сапраўды не пацярпелі, і насамрэч, праблем з працяглым чаканнем такіх рэчаў, як генерацыя ключоў GnuPG, стане паменш.
«Гэтыя серыі не павінны парушаць ніякіх існуючых праграм. /dev/urandom застаецца нязменным. /dev/random па-ранейшаму блакуецца адразу пасля загрузкі, але блакуецца менш, чым раней. getentropy () з існуючымі сцягамі верне вынік, які будзе такім жа прыдатным для практычных мэт, як і раней».
Лутамірскі зазначыў, што да гэтага часу застаецца адкрытым пытанне аб тым, ці павінна ядро прадастаўляць так званыя "сапраўдныя выпадковыя лікі", што ў пэўнай ступені і павінна было рабіць блакіруючае ядро. Ён бачыць для гэтага толькі адну прычыну: "выкананне дзяржаўных стандартаў". Лутамірскі выказаў меркаванне, што калі ўжо ядро павінна гэта забяспечыць, то гэта павінна быць зроблена праз зусім іншы інтэрфейс або павінна быць перанесена ў прастору карыстальніка, даўшы яму магчымасць здабываць неапрацаваныя ўзоры падзей, якія могуць быць скарыстаны для стварэння такога пула блакавання.
Штэфан Мюлер (Stephan Müller) выказаў здагадку, што яго набор для генератара выпадковых лікаў Linux (LRNG) (у цяперашні час выпушчана 26 версія) можа быць спосабам прадастаўлення сапраўдных выпадковых лікаў для прыкладанняў, якія маюць у гэтым патрэбу. LRNG "цалкам адпавядае патрабаванням "Рэкамендацый па крыніцах энтрапіі, якія выкарыстоўваюцца для генерацыі выпадковых бітаў" SP800-90B", што робіць яго рашэннем праблемы дзяржаўных стандартаў.
Мэцью Гарретт (Matthew Garrett) пярэчыў супраць тэрміна "праўдзівыя выпадковыя дадзеныя", адзначаючы, што выбіраемыя прылады ў прынцыпе могуць быць змадэляваныя дастаткова дакладна, каб зрабіць іх прадказальнымі: "мы тут не адбіраем квантавыя падзеі".
Мюлер адказаў, што гэты тэрмін паходзіць ад нямецкага стандарту AIS 31 для апісання генератара выпадковых лікаў, які толькі выдае вынік "з такой жа хуткасцю, з якой базавая крыніца шуму вырабляе энтрапію".
Акрамя розначытанняў тэрміналогіі, наяўнасць пула блакавання, як гэта прапануецца патчамі LRNG, проста прывядзе да розных праблем, па меншай меры, калі ён даступны без прывілеяў.
Як сказаў Лутамірскі: “Гэта не вырашае праблему. Калі два розных карыстальніка запускаюць дурныя праграмы, такія як gnupg, яны проста схуднеюць адзін аднаго. Я бачу, што ў наш час існуюць дзве асноўныя праблемы з /dev/random: ён схільны да DoS (т. е. знясілення рэсурсаў, шкоднаснаму ўплыву ці чамусьці падобнаму), і, паколькі ніякіх прывілеяў для яго выкарыстання не патрабуецца, ён таксама схільны да злоўжыванняў. Gnupg - гэта няправільна, гэта поўны калапс. Калі мы дадамо новы непрывілеяваны інтэрфейс, які будуць выкарыстоўваць gnupg і аналагічныя праграмы, мы зноў прайграем».
Мюлер адзначыў, што даданне getrandom() зараз дазволіць GnuPG выкарыстоўваць гэты інтэрфейс, паколькі ён забяспечыць неабходную гарантыю таго, што пул быў ініцыялізаваны. На аснове дыскусій з распрацоўшчыкам GnuPG Вернерам Кохам (Werner Koch) Мюлер лічыць, што гарантыя – гэта адзіная прычына, па якой GnuPG у цяперашні час чытае непасрэдна з /dev/random. Але калі ёсць непрывілеяваны інтэрфейс, які схільны адмове ў абслугоўванні (як на сёння /dev/random), то па сцвярджэнні Лутамірскага, ён будзе няправільна выкарыстоўвацца некаторымі прыкладаннямі.
Тэадор Цао (Theodore Yue Tak Ts'o), распрацоўшчык падсістэмы выпадковых лікаў Linux, відаць, змяніў сваё меркаванне з нагоды неабходнасці блакавальнага пула. Ён сказаў, што выдаленне гэтага пула дазволіць эфектыўна пазбавіцца ад ідэі, што Linux мае сапраўдны генератар выпадковых лікаў (TRNG): "гэта не з'яўляецца бязглуздзіцай, бо гэта менавіта тое, што заўсёды рабілі *BSD".
Ён таксама занепакоены тым, што падаванне механізму TRNG будзе проста служыць у якасці прынады для распрацоўнікаў прыкладанняў і лічыць, што насамрэч, улічваючы розныя тыпы апаратнага забеспячэння, падтрымоўванага Linux, немагчыма гарантаваць TRNG у ядры. Праблему не вырашыць нават магчымасць працы з абсталяванне толькі на аснове root-прывілеяў: "Распрацоўшчыкі прыкладных праграм паказваюць, каб іх прыкладанне ў мэтах бяспекі было ўсталявана як root, таму толькі так вы можаце атрымаць доступ да "сапраўды добрых" выпадковым лікам".
Мюлер спытаў, ці не адмовіўся Цао ад рэалізацыі блакіруючага пула, якую ён сам даўно прапанаваў. Цао адказаў, што плануе ўзяць патчы Лутамірскага і актыўна пярэчыць супраць дадання блакіруючага інтэрфейсу назад у ядро.
«Ядро не можа даць ніякіх гарантый наконт таго, ці быў ахарактарызаваны noise source належным чынам. Адзінае, што можа атрымаць распрацоўшчык GPG або OpenSSL – гэта цьмянае адчуванне, што TRUERANDOM "лепш", а паколькі яны хочуць большай бяспекі, то, несумненна, паспрабуюць яго выкарыстоўваць. У пэўны момант ён заблакуецца, і калі які-небудзь іншы разумны карыстач (магчыма, адмысловец па выпуску дыстрыбутыва) уставіць яго ў init скрыпт і сістэмы перастануць працаваць, карыстачам застанецца толькі жаліцца самому Лінусу Торвальдсу».
Цао таксама выступае за тое, каб даць крыптаграфіі і тым, хто сапраўды мае патрэбу ў TRNG, спосаб збіраць сваю ўласную энтрапію ў карыстацкай прасторы, каб выкарыстоўваць яе па сваім меркаванні. Ён кажа, што збор энтрапіі - гэта не той працэс, які можа выконвацца ядром на разнастайных падтрымліваемых ім апаратных сродках, акрамя таго, само ядро не можа ацаніць колькасць энтрапіі, якая забяспечваецца рознымі крыніцамі.
«Ядро не павінна змешваць разам розныя noise source, і яно, вядома ж, не павінна спрабаваць сцвярджаць, што ведае, колькі біт энтрапіі яно атрымлівае, калі спрабуе гуляць у нейкую «дерганную гульню энтрапіі» на просты да бязладдзя архітэктуры CPU для карыстацкіх выпадкаў IOT/Embedded, калі ўсё рассінхранізавана з адзіным майстар-генератарам, калі няма ніякай інструкцыі CPU для пераўпарадкавання ці перайменавання рэгістра і т. д.».
«Можна казаць аб прадастаўленні інструментаў, якія спрабуюць зрабіць гэтыя разлікі, але такія рэчы павінны праводзіцца на абсталяванні кожнага карыстальніка, што для большасці карыстальнікаў дыстрыбутыва проста непрактычна. Калі ж гэта прызначана толькі для крыптографаў, то няхай будзе зроблена ў іх карыстацкай прасторы. І давайце не будзем спрашчаць GPG, OpenSSL і т. д., каб усё казалі: "мы жадаем "праўдзівай выпадковасці" і не згодны на меншае". Можна казаць пра тое, як мы даем інтэрфейсы крыптографам, каб яны маглі атрымаць неабходную інфармацыю дзякуючы доступу да першасных noise sources, аддзеленых і пайменаваных, і, магчыма, што нейкім чынам noise source зможа аўтэнтыфікаваць сябе ў бібліятэцы або дадатку карыстацкай прасторы».
Мела месца невялікая дыскусія аб тым, як можа выглядаць такі інтэрфейс, бо, напрыклад, для некаторых падзей могуць быць наступствы ў плане бяспекі. Цао адзначыў, што коды сканавання клавіятуры (гэта значыць націску клавіш) змешваюцца ў пул як частка збору энтрапіі: "Перанос гэтага ў карыстацкую прастору, нават праз прывілеяваны сістэмны выклік, было б, па меншай меры, неразважліва". Магчыма, што і іншыя таймінгі падзей могуць стварыць нейкую ўцечку інфармацыі па пабочных каналах.
Такім чынам, узнікае адчуванне, што даўняя праблема падсістэмы выпадковых лікаў Linux знаходзіцца на шляхі да рашэння. Змены, якія падсістэма выпадковых лікаў зведала ў апошні час, фактычна прыводзілі толькі да праблем DoS падчас яе выкарыстання. Зараз жа з'явіліся эфектыўныя спосабы атрымаць найлепшыя выпадковыя лікі, якія толькі можа падаць ядро. Калі ж TRNG усё яшчэ пажаданы для Linux, то гэты недахоп трэба будзе ўхіліць у будучыні, але, хутчэй за ўсё, гэта не будзе рабіцца ўсярэдзіне самога ядра.
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com