Както е известно, /dev/random, криптографски устойчивият генератор на псевдослучайни числа (CSPRNG), има един неприятен проблем – блокировки. В тази статия се описва как може да се реши този проблем.
През последните няколко месеца средствата за генериране на случайни числа в ядрото бяха малко преработени, но проблемите в тази подсистема се решават от по-дълго време. . Най- бяха направени с цел да се предотврати дълга блокировка на системния повик getrandom() при зареждане на системата, но причината за това бе поведението на блокирания случайния пул. Недавен патч би премахнал този пул и се очакваше, че ще бъде интегриран в основното ядро.
Анди Лутомирски (Andy Lutomirski) публикува третата версия на патча в края на декември. Той внася "две основни семантични промени в Linux API за случайни числа". Патчът добавя нов флаг GRND_INSECURE към системния повик getrandom() (въпреки че Лутомирски го нарича getentropy(), който е реализиран в glibc с помощта на getrandom() с фиксирани флагове); този флаг принуждава повика да винаги връща количеството поисканите данни, но без гаранция, че тези данни са случайни. Ядрото просто ще се постарае да предостави най-добрите случайни данни, които има в момента. "Вероятно най-доброто, което можете да направите, е да го наречете 'INSECURE' (небезопасен), за да попречите на използването на това API за неща, които се нуждаят от сигурност." (несигурен), за да предотвратите използването на това 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() с съществуващите флагове ще върне резултат, който ще бъде толкова подходящ за практически цели, колкото и преди.“
Лутомирски отбеляза, че все още остава открит въпросът дали ядрото трябва да предоставя така наречените „истински случайни числа“, което до известна степен е трябвало да прави блокиращото ядро. Той вижда единствено една причина за това: „спазване на държавни стандарти“. Лутомирски предположи, че ако ядрото трябва да осигури това, то трябва да бъде направено посредством напълно различен интерфейс или да бъде прехвърлено в потребителското пространство, предоставяйки възможност за извличане на необработени проби от събития, които могат да бъдат използвани за създаване на такъв блокиращ пул.“
Штефан Мюллер (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 два пъти по-евтин в дата-центъра Equinix Tier IV в Амстердам? Само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Четете за това
Източник: habr.com
