/dev/random, криптографски защитен генератор на псевдослучайни числа (CSPRNG), е известно, че има един досаден проблем: блокиране. Тази статия обяснява как можете да го разрешите.
През последните няколко месеца съоръженията за генериране на произволни числа в ядрото бяха леко преработени, но проблемите в тази подсистема бяха решени в хода на по-широкото . Повечето бяха направени, за да се предотврати блокирането на системното извикване getrandom() за дълго време, когато системата се зарежда, но основната причина за това беше блокиращото поведение на произволния пул. Скорошна корекция би премахнала този пул и се очакваше да се насочи към основното ядро.
Анди Лутомирски публикува третата версия на пача в края на декември. Той допринася "две големи семантични промени в произволни API на Linux". Пачът добавя нов флаг 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() със съществуващите флагове ще върне резултат, който е също толкова подходящ за практически цели, колкото и преди."
Лутомирски отбеляза, че все още е открит въпросът дали ядрото трябва да предоставя така наречените „истински случайни числа“, което е трябвало да прави до известна степен блокиращото ядро. Той вижда само една причина за това: „съответствие с държавните стандарти“. Lutomirsky предложи, ако ядрото трябва да осигури това, това трябва да се направи чрез напълно различен интерфейс или трябва да бъде преместено в потребителското пространство, позволявайки на потребителя да извлича необработени проби от събития, които могат да се използват за създаване на такъв пул за заключване.
Щефан Мюлер предложи неговия комплект за Linux генератор на произволни числа (LRNG) (понастоящем издадена версия 26) може да бъде начин за предоставяне на истински произволни числа за приложения, които се нуждаят от него. LRNG е „напълно съвместим с указанията SP800-90B за източници на ентропия, използвани за генериране на произволни битове“, което го прави решение на проблема с държавните стандарти.
Матю Гарет възрази срещу термина „истински произволни данни“, отбелязвайки, че взетите проби от устройства по принцип могат да бъдат моделирани достатъчно точно, за да ги направят предвидими: „тук не вземаме проби от квантови събития“.
Мюлер отговори, че терминът идва от немския стандарт AIS 31, за да опише генератор на произволни числа, който произвежда само резултат „със същата скорост, с която основният източник на шум произвежда ентропия“.
Като оставим настрана терминологичните разлики, наличието на пул за заключване, както е предложено от LRNG пачовете, просто ще доведе до различни проблеми, поне ако се осъществява достъп без привилегии.
Както каза Лютомирски: „Това не решава проблема. Ако двама различни потребители стартират глупави програми като gnupg, те просто ще се източват взаимно. Виждам, че в момента има два основни проблема с /dev/random: предразположен е към DoS (т.е. изчерпване на ресурси, злонамерено влияние или нещо подобно) и тъй като не са необходими привилегии за използването му, той също е предразположен към злоупотреба. Gnupg е грешен, това е пълен колапс. Ако добавим нов непривилегирован интерфейс, който gnupg и подобни програми ще използват, ще загубим отново."
Мюлер отбеляза, че добавянето на getrandom() вече ще позволи на GnuPG да използва този интерфейс, тъй като ще предостави необходимата гаранция, че пула е инициализиран. Въз основа на дискусии с разработчика на GnuPG Вернер Кох, Мюлер вярва, че гаранцията е единствената причина GnuPG в момента да чете директно от /dev/random. Но ако има непривилегирован интерфейс, който е податлив на отказ на услуга (както /dev/random е днес), Лутомирски твърди, че той ще бъде злоупотребен от някои приложения.
Theodore Yue Tak Ts'o, разработчик на подсистемата за произволни числа на Linux, изглежда е променил мнението си относно необходимостта от блокиращ пул. Той каза, че премахването на този пул ефективно ще се отърве от идеята, че Linux има истински генератор на случайни числа (TRNG): "това не са глупости, тъй като това е точно това, което *BSD винаги е правил."
Той също така е загрижен, че предоставянето на TRNG механизъм просто ще служи като примамка за разработчиците на приложения и вярва, че всъщност, предвид различните видове хардуер, поддържан от Linux, е невъзможно да се гарантира TRNG в ядрото. Дори способността да работите с оборудване само с root права няма да реши проблема: „Разработчиците на приложения уточняват тяхното приложение да бъде инсталирано като root за целите на сигурността, така че това е единственият начин да имате достъп до „наистина добрите“ произволни числа.“
Мюлер попита дали Cao е изоставил внедряването на блокиращия пул, което самият той отдавна беше предложил. Cao отговори, че планира да вземе пачовете на Lutomirsky и активно се противопоставя на добавянето на блокиращ интерфейс обратно към ядрото.
„Ядрото не може да даде гаранции дали източникът на шум е правилно характеризиран. Единственото нещо, което GPG или OpenSSL разработчикът може да получи, е смътното усещане, че TRUERANDOM е "по-добър" и тъй като те искат повече сигурност, те несъмнено ще се опитат да го използват. В един момент той ще бъде блокиран и когато някой друг интелигентен потребител (може би специалист по дистрибуция) го вмъкне в началния скрипт и системите спрат да работят, потребителите ще трябва само да се оплачат на самия Линус Торвалдс.
Cao също така се застъпва за предоставяне на криптографи и тези, които действително се нуждаят от TRNG, начин да съберат собствената си ентропия в потребителското пространство, която да използват, както намерят за добре. Той казва, че събирането на ентропия не е процес, който може да се извърши от ядрото на целия различен хардуер, който поддържа, нито самото ядро може да оцени количеството ентропия, осигурено от различни източници.
„Ядрото не трябва да смесва различни източници на шум заедно и със сигурност не трябва да се опитва да твърди, че знае колко бита ентропия получава, когато се опитва да играе някаква „игра с трептене на ентропия“ на безобразно прост процесор архитектура за потребителски потребители IOT/вградени случаи, когато всичко не е синхронизирано с един главен осцилатор, където няма инструкция на процесора за пренареждане или преименуване на регистър и т.н.
„Можете да говорите за предоставяне на инструменти, които се опитват да направят тези изчисления, но такива неща трябва да се правят на хардуера на всеки потребител, което просто не е практично за повечето потребители на разпространение. Ако това е предназначено само за криптографи, оставете го да бъде направено в тяхното потребителско пространство. И нека не опростяваме GPG, OpenSSL и т.н., така че всеки да казва „ние искаме „истинска произволност“ и няма да се примирим с по-малко“. Можем да говорим за това как предоставяме интерфейси на криптографите, така че те да могат да получат информацията, от която се нуждаят, чрез достъп до първичните източници на шум, разделени и наименувани, и може би по някакъв начин източникът на шум може да се удостовери в библиотека или приложение за потребителско пространство.
Имаше известна дискусия за това как може да изглежда такъв интерфейс, тъй като например може да има последици за сигурността за някои събития. Cao отбеляза, че кодовете за сканиране на клавиатурата (т.е. натисканията на клавиши) се смесват в пул като част от събирането на ентропия: „Вкарването на това в потребителското пространство, дори чрез привилегировано системно повикване, би било най-малкото неразумно.“ Напълно възможно е други времена на събития да създадат някакъв вид изтичане на информация през странични канали.
Така че изглежда, че дългогодишен проблем с подсистемата за произволни числа на Linux е на път да намери решение. Промените, които наскоро претърпя подсистемата за произволни числа, всъщност доведоха само до проблеми с DoS, докато я използвате. Сега има ефективни начини за получаване на най-добрите произволни числа, които ядрото може да предостави. Ако TRNG все още е желателно в Linux, тогава този недостатък ще трябва да бъде решен в бъдеще, но най-вероятно това няма да бъде направено в самото ядро.
Малко реклами 🙂
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с 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! Прочети за
Източник: www.habr.com