/dev/random, криптографски безбеден генератор на псевдо-случајни броеви (CSPRNG), е познато дека има еден досаден проблем: блокирање. Оваа статија објаснува како можете да го решите.
Во текот на изминатите неколку месеци, капацитетите за генерирање на случаен број во јадрото беа малку преработени, но проблемите во овој потсистем беа решени во текот на поширокото . Најмногу беа направени за да се спречи системскиот повик getrandom() да се блокира долго време кога системот ќе се подигне, но основната причина за ова беше однесувањето на блокирање на случајниот базен. Неодамнешниот лепенка би го отстранил овој базен и би се очекувало да се упати кон главното јадро.
Енди Лутомирски ја објави третата верзија на лепенката на крајот на декември. Тој придонесува „две главни семантички промени на случајни Linux API“. Закрпата додава ново знаменце GRND_INSECURE на системскиот повик getrandom() (иако Лутомирски го нарекува getentropy(), што се имплементира во glibc користејќи getrandom() со фиксни знаменца); ова знаменце предизвикува повикот секогаш да ја враќа бараната количина на податоци, но без да гарантира дека податоците се случајни. Јадрото едноставно ќе даде се од себе за да ги произведе најдобрите случајни податоци што ги има во даденото време. „Веројатно најдоброто нешто што може да се направи е да се нарече „НЕСИГУРНО“ (небезбедно) за да се спречи користењето на овој API за работи на кои им е потребна безбедност."
Закрпите го отстрануваат и блокирачкиот базен. Јадрото моментално одржува два случајни базени на податоци, еден што одговара на /dev/random, а другиот на /dev/urandom, како што е опишано во ова 2015 година. Базенот за блокирање е базенот за /dev/random; читања за тој уред ќе блокира (значи неговото име) додека не се собере „доволно“ ентропија од системот за да се задоволи барањето. Понатамошните читања од оваа датотека се исто така блокирани ако нема доволно ентропија во базенот.
Отстранувањето на базенот за заклучување значи дека читањето од /dev/random се однесува како getrandom() со знаменца поставени на нула (и го претвора знамето GRND_RANDOM во noop). Откако ќе се иницијализира криптографскиот генератор на случаен број (CRNG), читањето од /dev/random и повиците до getrandom(...,0) нема да блокираат и ќе ја вратат бараната количина на случајни податоци.
Лутомирски вели: „Верувам дека базенот за блокирање на Linux стана застарен. CRNG Linux генерира излез што е доволно добар дури и да се користи за генерирање клучеви. Блокирачкиот базен не е посилен во никаква материјална смисла и бара многу инфраструктура со сомнителна вредност за да се поддржи“.
Промените беа направени со цел да се осигура дека постоечките програми нема да бидат засегнати, а всушност, ќе има помалку проблеми со долго чекање за работи како што е генерирањето клучеви GnuPG.
„Овие епизоди не смеат да нарушат ниту една постоечка програма. /dev/urandom останува непроменет. /dev/random сè уште блокира веднаш по подигнувањето, но блокира помалку од порано. getentropy() со постојните знаменца ќе врати резултат кој е исто толку погоден за практични цели како и досега."
Лутомирски истакна дека сè уште е отворено прашање дали кернелот треба да обезбеди таканаречени „вистински случајни броеви“, што до одреден степен требаше да го направи кернелот за блокирање. Тој гледа само една причина за тоа: „усогласеност со владините стандарди“. Лутомирски предложи дека ако јадрото треба да го обезбеди ова, тоа треба да се направи преку сосема поинаков интерфејс, или треба да се премести во корисничкиот простор, дозволувајќи му на корисникот да добие необработени примероци од настани што би можеле да се користат за создавање таков базен за заклучување.
Стефан Милер го предложи својот сет за Linux Random Number Generator (LRNG) (моментално објавена верзија 26) може да биде начин да се обезбедат вистински случајни броеви за апликациите на кои им е потребен. LRNG е „целосно усогласен со упатствата SP800-90B за извори на ентропија што се користат за генерирање случајни битови“, што го прави решение за проблемот со владините стандарди.
Метју Гарет се спротивстави на терминот „вистински случајни податоци“, истакнувајќи дека уредите земени во принцип може да се моделираат доволно прецизно за да бидат предвидливи: „ние овде не земаме примероци од квантни настани“.
Милер одговори дека терминот доаѓа од германскиот стандард AIS 31 за да опише генератор на случаен број кој произведува само резултат „со иста брзина како што основниот извор на бучава произведува ентропија“.
Настрана разликите во терминологијата, имањето базен за заклучување како што е предложено од закрпите на LRNG едноставно ќе доведе до разни проблеми, барем ако се пристапува без привилегии.
Како што рече Лутомирски: „Ова не го решава проблемот. Ако два различни корисници водат глупави програми како gnupg, тие само ќе се исцедат еден со друг. Гледам дека моментално има два главни проблеми со /dev/random: тој е склон кон DoS (т.е. исцрпување на ресурсите, злонамерно влијание или нешто слично), и бидејќи не се потребни никакви привилегии за негово користење, исто така е склон на злоупотреба. Gnupg не е во ред, тоа е целосен колапс. Ако додадеме нов непривилегиран интерфејс што ќе го користат gnupg и слични програми, повторно ќе изгубиме“.
Мулер забележа дека додавањето getrandom() сега ќе му овозможи на GnuPG да го користи овој интерфејс, бидејќи ќе ја обезбеди потребната гаранција дека базенот е иницијализиран. Врз основа на разговорите со развивачот на GnuPG, Вернер Кох, Мулер верува дека гаранцијата е единствената причина зошто GnuPG моментално чита директно од /dev/random. Но, ако постои непривилегиран интерфејс кој е подложен на одбивање на услугата (како што е денес /dev/random), Лутомирски тврди дека тој ќе биде злоупотребен од некои апликации.
Теодор Ју Так Цо, развивач на потсистемот за случаен број на Линукс, се чини дека се предомислил за потребата од блокирачки базен. Тој рече дека отстранувањето на овој базен ефикасно ќе се ослободи од идејата дека Linux има вистински генератор на случаен број (TRNG): „Ова не е глупост, бидејќи ова е токму она што *BSD секогаш го правеше“.
Тој, исто така, е загрижен дека обезбедувањето механизам TRNG едноставно ќе послужи како мамка за развивачите на апликации и верува дека всушност, со оглед на различните типови на хардвер поддржани од Linux, невозможно е да се гарантира TRNG во кернелот. Дури и можноста за работа со опрема само со права на root нема да го реши проблемот: „Програмерите на апликации специфицираат нивната апликација да биде инсталирана како root за безбедносни цели, така што ова е единствениот начин на кој можете да пристапите до „навистина добрите“ случајни броеви“.
Мулер праша дали Као ја напуштил имплементацијата на блокирачкиот базен што тој самиот долго време го предлагал. Као одговори дека планира да ги земе закрпите на Лутомирски и активно се противи на додавање блокирачки интерфејс назад во кернелот.
„Јадрото не може да даде никакви гаранции за тоа дали изворот на бучава е правилно карактеризиран. Единственото нешто што може да го добие развивачот на GPG или OpenSSL е нејасно чувство дека TRUERANDOM е „подобар“ и бидејќи сакаат поголема безбедност, несомнено ќе се обидат да го користат. Во одреден момент ќе биде блокиран, а кога некој друг паметен корисник (можеби специјалист за дистрибуција) ќе го вметне во почетната скрипта и системите ќе престанат да работат, корисниците ќе треба само да се жалат на самиот Линус Торвалдс“.
Као, исто така, се залага да им се даде на криптографите и на оние на кои всушност им е потребен TRNG начин да ја соберат сопствената ентропија во корисничкиот простор за да ја користат како што им одговара. Тој вели дека собирањето ентропија не е процес што може да го изврши кернелот на целиот различен хардвер што го поддржува, ниту пак самиот кернел може да ја процени количината на ентропија обезбедена од различни извори.
„Јадрото не треба да меша различни извори на бучава заедно, и секако не треба да се обидува да тврди дека знае колку битови ентропија добива кога се обидува да игра некаква „игра со тенка ентропија“ на неверојатно едноставен процесор архитектура за корисници на потрошувачи. IOT/Вградени случаи каде што сè не е синхронизирано со еден главен осцилатор, каде што не постои инструкција на процесорот за прередување или преименување на регистар итн.“
„Можете да зборувате за обезбедување алатки кои се обидуваат да ги направат овие пресметки, но такви работи треба да се прават на хардверот на секој корисник, што едноставно не е практично за повеќето корисници на дистрибуција. Ако ова е наменето само за криптографи, тогаш нека се направи во нивниот кориснички простор. И да не ги поедноставуваме GPG, OpenSSL итн., па сите да кажат „сакаме „вистинска случајност“ и нема да се задоволиме со помалку“. Можеме да зборуваме за тоа како им обезбедуваме интерфејси на криптографите за да можат да ги добијат информациите што им се потребни со пристап до примарните извори на бучава, одделени и именувани, а можеби некако изворот на бучава може да се автентицира во библиотека или апликација за кориснички простор“.
Имаше одредена дискусија за тоа како би можел да изгледа таков интерфејс, бидејќи на пример може да има безбедносни импликации за некои настани. Као забележа дека шифрите за скенирање на тастатурата (т.е. притискање на копчињата) се мешаат во базен како дел од колекцијата на ентропија: „Да се донесе ова во корисничкиот простор, дури и преку привилегиран системски повик, во најмала рака би било немудро“. Сосема е можно други тајминзи на настани да создадат некаков вид истекување на информации преку страничните канали.
Значи, изгледа дека долгогодишниот проблем со потсистемот за случаен број на Linux е на пат кон решение. Промените што неодамна ги претрпе потсистемот со случаен број всушност резултираа само со проблеми со DoS додека го користите. Сега постојат ефикасни начини да ги добиете најдобрите случајни броеви што може да ги обезбеди кернелот. Ако TRNG е сè уште пожелен на Linux, тогаш овој недостаток ќе треба да се реши во иднина, но најверојатно тоа нема да се направи во самиот кернел.
Некои реклами 🙂
Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, , уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB DDR4).
Dell R730xd 2 пати поевтин во центарот за податоци Equinix Tier IV во Амстердам? Само овде во Холандија! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - од 99 долари! Прочитајте за
Извор: www.habr.com